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ABSTRACT 


This  dissertation  addresses  the  need  for  a  formal  method  to  support  the  merging  of 
changes  in  independently  developed  versior  a,  prototype  in  *  computer-aided  rapid  pro¬ 
totyping  system.  The  goal  is  to  provide  the  .  .otype  developer  with  the  ability  to:  combine 
independently  developed  enhancements  to  a  prototype,  check  for  consistency,  and  automat¬ 
ically  update  all  derived  versions  of  a  prototype  with  changes  made  to  the  base  version. 


A  useful  semantics-based  method  is  provided  for  change-merging  that  is  guaranteed  to 
detect  all  conflicts.  Prototype  slicing  is  used  to  capture  the  affected  parts  of  each  variation 
and  the  preserved  part  of  the  base  in  both  variations.  V*  ..■■■£.  combine  the  affected  parts 
with  the  preserved  part  using  our  model,  which  includes  the  firs*  use  of  Brouwerian  Algebras 
to  formalize  the  merging  of  hard  real  time  constraints.  Our  Slicing  Theorem  guarantees  that 
this  method  produces  a  prototype  that  correctly  exhibits  the  significant  behavior  of  each  of 
the  input  versions,  provided  the  changes  do  not  conflict.  The  method  achieves  correctness 
by  comparing  the  slice  of  the  change-merged  version  with  respect  to  each  affected  part 
against  the  same  slice  of  the  appropriate  changed  version.  If  the  slices  are  the  same,  the 
change-merge  is  correct,  otherwise  a  diagnostic  message  results.  A  preliminary  conditional 
method  for  change-merging  while  programs  is  also  provided  that  is  strictly  more  accurate 
than  previous  methods. 


This  dissertation  contributes  to  computer-aided  software  maintenance  by  providing  a 
model,  algorithm  and  implementation  for  an  automated  change-merging  tool  for  PSDL  pro-  :or” 
totypes.  Preliminary  testing  shows  that  this  tool  will  enhance  the  ability  of  the  prototype 
developer  to  deliver  a  prototype  in  less  time  by  enabling  more  concurrency  in  the  develop-  in_ 
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I.  INTRODUCTION 


During  iterative  development  of  software  prototypes,  different  variations  are  generally 
developed  where  each  of  the  versions  contains  a  portion  of  the  desired  capability.  Because 
these  prototypes  can  be  very  large,  tools  that  automatically  determine  the  differences  be¬ 
tween  these  versions  and  produce  a  new  version  exhibiting  significant  behavior  from  each 
axe  desirable.  This  dissertation  defines  a  change-merging  method  that  is  semantics-based 
and  guarantees  that  if  a  conflict-free  result  is  produced,  it  is  semantically  correct,  and  pro¬ 
vides  a  working  change-merging  tool  to  be  integrated  into  the  Computer-Aided  Prototyping 
System  (CAPS).  Traditional  syntax-based  merging  tools  fall  short  of  providing  results  guar¬ 
anteed  to  be  semantically  correct,  and  earlier  semantics-based  change-merging  or  integration 
methods  concentrated  on  combining  changes  to  simple  imperative  or  while  programs.  We 
explore  a  domain  of  enhanced  data  flow  programs ,  written  in  PSDL,  which  are  inherently 
non-detenninistic  and  parallel.  Our  change-merging  method  provides  the  first  real  change- 
merging  capability  for  this  domain  of  programs. 

Software  change-merging  is  also  applicable  to  software  maintenance  activities.  As¬ 
suming  that  a  software  system  has  been  developed  using  the  computer-aided  prototyping 
paradigm,  or  can  be  translated  into  the  prototyping  language,  different  versions  of  that  soft¬ 
ware  can  be  automatically  updated  with  changes  made  to  the  base  version  by  applying  our 
method.  The  fielded  version  would  be  one  variation  and  the  updated  base  version  would 
be  the  other  variation.  If  all  of  the  changes  made  to  the  base  version  are  compatible  with 
the  fielded  version,  applying  our  method  results  in  a  new  fielded  version  updated  with  the 
changes  made  to  the  base  version.  If  the  changes  are  not  compatible,  this  information  is  pro¬ 
vided  automatically  by  our  method.  Using  this  technology  eliminates  the  need  for  software 
designers  to  manually  check  if  changes  are  compatible  before  performing  updates.  It  also 
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alkwi  fewer  designer*  to  make  change*  to  existing  software  systems,  as  well  as  prototypes 
in  development.  In  an  industry  with  projected  costs  in  the  billions  of  dollars  [Ref.  40],  fhis 
translates  into  significant  savings  to  both  the  software  developer  and  the  customer. 

Other  uses  of  this  technology  are  found  in  the  areas  of  software  reuse  and  reengineering. 
In  software  reuse,  complex  reusable  components  can  be  retrieved  from  the  software  repository 
that  contain  more  functionality  than  is  required  for  the  application.  The  desired  functionality 
can  be  isolated  using  prototype  slicing  by  taking  the  slice  of  the  complex  component  with 
respect  to  the  output  streams  desired.  The  resultant  slice  will  contain  any  part  of  the  complex 
component  that  affects  the  output  stream.  In  reengineering,  if  a  program  written  in  some 
high-level  language  can  be  translated  into  the  prototyping  language,  PSDL,  then  changes 
made  to  the  prototype  version  of  the  base  program  can  be  automatically  incorporated  into 
the  prototype  versions  of  the  target  programs,  and  the  resultant  prototype  can  then  be  used 
to  generate  new  production  code  for  the  reengineered  program. 

A.  RAPID  PROTOTYPING 

Rapid  prototyping  is  an  approach  to  software  development  that  was  introduced  to 
overcome  the  following  weaknesses  of  traditional  approaches: 

1.  Fully  developed  software  systems  that  do  not  satisfy  the  customer’s  needs,  or  are 
obsolete  upon  release. 

2.  No  capability  for  accurately  evaluating  real-time  requirements  before  the  software 
system  has  been  built. 

To  overcome  these  weaknesses,  computer-aided  software  development  methods  must  be 
developed  which  ensure  accurate  requirements  engineering  and  emphasize  efficient  change 
incorporation  both  during  development  and  after  fielding  of  the  software  system.  Computer- 
Aided  Rapid  Prototyping  is  one  such  methodology.  Rapid  prototyping  overcomes  these 
weaknesses  by  increasing  customer  interaction  during  the  requirements  engineering  phase 
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of  development,  providing  executable  specifications  that  can  be  evaluated  for  conformance 
to  real-time  requirements,  and  producing  a  production  software  system  in  a  fraction  of  the 
time  required  using  traditional  methods.  Rapid  prototyping  allows  the  user  to  get  a  bet¬ 
ter  understanding  of  requirements  early  in  the  conceptual  design  phase  of  development.  It 
involves  the  use  of  software  tools  to  rapidly  create  concrete  executable  models  of  selected 
aspects  of  a  proposed  system  to  allow  the  user  to  view  the  model  and  make  comments  early. 
The  prototype  is  rapidly  reworked  and  redemonstrated  to  the  user  over  several  iterations 
until  the  designer  and  the  user  have  a  precise  view  of  what  the  system  should  do.  This  pro¬ 
cess  produces  a  validated  set  of  requirements  which  become  the  basis  for  designing  the  final 
product  [Ref.  36].  The  prototype  can  also  be  transformed  into  part  of  the  final  product.  In 
some  prototyping  methodologies,  prototypes  are  developed,  demonstrated  and  then  thrown 
away  before  the  production  system  is  developed.  In  prototyping  methodologies  like  the  one 
used  in  CAPS,  the  prototype  is  an  executable  shell  of  the  final  system,  containing  a  subset 
of  the  system’s  ultimate  functionality.  After  the  design  of  the  prototype  is  approved  by  the 
customer,  the  missing  functionality  is  added  and  the  system  is  delivered.  In  this  approach 
to  rapid  prototyping,  software  systems  can  be  delivered  incrementally  as  parts  of  the  sys¬ 
tem  become  fully  operational.  Figure  1.1  shows  the  life-cycle  model  for  this  prototyping 
methodology. 

In  this  model,  the  customer  provides  a  set  of  initial  goals  to  the  designer.  The  designer 
takes  those  initial  goals  and  formulates  a  set  of  requirements  from  which  the  first  version  of 
the  prototype  is  designed.  This  prototype  is  then  demonstrated  to  the  user,  with  the  user 
providing  feedback  to  the  designer.  The  designer  takes  the  feedback,  adjusts  the  requirements 
to  reflect  the  adjusted  goals  and  makes  whatever  changes  to  the  prototype  necessary  to 
satisfy  the  requirements.  It  is  then  redemonstrated  to  the  user  for  more  feedback.  This 
iterative  process  continues  until  a  validated  set  of  requirements  is  accepted  by  the  user.  The 
designer  then  takes  the  prototype  and  implements  the  remainder  of  the  functionality  needed 
to  produce  the  operational  system.  The  result  is  an  operational  software  system  that  satisfies 
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Figure  1.1:  Rapid  Prototyping  Life-Cycle  Model.  [Ref.  20] 


the  customer’s  requirements  and  that  is  delivered  in  only  a  fraction  of  the  time  it  would  take 
using  traditional  software  development  methods 

Change-merging  is  an  integral  part  of  the  rapid  prototyping  methodology.  During  the 
Design  Prototype  System  phase  of  prototype  development,  multiple  variations  of  a  large  pro¬ 
totype  are  likely  to  be  developed.  This  can  happen  when  different  development  teams  are 
working  on  different  aspects  of  a  system,  or  when  different  possible  solutions  to  a  problem 
are  explored  in  different  ways.  In  the  first  example,  it  will  certainly  be  necessary  for  the  sepa¬ 
rately  developed  pieces  of  the  prototype  to  be  combined  into  a  single  system  before  execution 
for  the  customer.  In  the  second  example,  the  customer  may  desire  a  system  containing  some 
or  all  of  the  aspects  contained  in  each  solution.  In  this  case,  these  different  prototypes  must 
be  change-merged  to  capture  the  significant  parts  of  each  variation.  Our  change-merging 
method  will  allow  these  combinations  to  be  done  automatically,  ensuring  that  the  resultant 
prototype  is  semantically  correct,  with  respect  to  all  of  the  input  variations.  If  the  pieces  are 
not  compatible  with  regard  to  the  semantics  of  the  prototype,  then  our  method  will  identify 
the  parts  of  the  prototype  containing  the  conflicts.  This  technology  encourages  the  designer 
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to  explore  different  solutions  to  &  problem,  and  to  spread  the  development  workload  in  a 
large  project  without  concern  for  the  subsequent  integration  of  these  independent  efforts. 

B.  PROTOTYPING  SYSTEM  DESCRIPTION  LANGUAGE 

Our  method  has  been  implemented  for  use  in  the  CAPS  development  system.  It  is 
designed  to  operate  on  programs  written  in  the  Prototyping  System  Description  Language 
(PSDL),  associated  with  CAPS.  PSDL  is  a  high  level  specification  and  design  language  which 
can  be  translated  into  executable  code. 

PSDL  is  a  generalisation  and  extension  of  a  data  flow  language,  with  the  addition 
of  control  constraints  and  timing  operations  [Ref.  35].  A  PSDL  prototype  consists  of  two 
parts:  a  specification  and  an  implementation.  The  specification  of  a  prototype  contains 
the  interface,  and  the  implementation  contains  either  a  PSDL  graph  implementation,  or  a 
programming  language  implementation.  The  PSDL  graph  implementation  contains  a  set  of 
operators,  a  set  of  data  streams  through  which  the  operators  communicate  with  one  another, 
and  a  set  of  control  and  timing  constraints  whidi  specify  restrictions  on  the  execution  of  the 
operators  or  data  streams.  The  programming  language  implementation  is  written  in  any 
high-level  programming  language  like  Ada  or  C  that  is  supported  by  the  environment. 

All  operators  in  PSDL  prototypes  are  state  machines.  Since  PSDL  is,  by  definition, 
non-deterministic,  the  meaning  of  an  operator  in  PSDL  is  a  mathematical  relation.  PSDL 
operators  with  only  one  state,  or  an  empty  set  of  state  variables,  and  only  one  possible  out¬ 
come  are  functions.  This  meaning  is  defined  by  the  operator’s  possibility  function  discussed 
in  a  later  section. 

A  data  stream  in  a  PSDL  prototype  is  a  communications  link  between  operators.  Each 
data  stream  is  either  a  data  flow  stream  or  a  sampled  stream.  Data  flow  streams  are  FIFO 
buffers  of  lengths  at  least  one.  When  a  new  value  is  written  to  the  stream,  it  is  appended 
to  the  buffer.  Values  are  removed  from  a  data  flow  stream  only  when  they  are  read  by  the 


container.  Velvet  on  data  flow  streams  can  be  read  only  once.  Sampled  streams  are  not 
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traditional  data  flow  streams.  They  have  buffers  of  size  one.  When  a  value  is  written  to  the 
stream,  it  remains  on  the  stream  until  a  new  value  is  written  to  the  stream,  at  which  time 
the  old  value  is  overwritten.  A  value  is  not  removed  from  the  sampled  stream  when  read. 
Data  streams  can  be  written  by  more  than  one  operator,  and  they  can  be  read  by  more  than 
one  operator.  A  complete  listing  of  the  PSDL  grammar  is  contained  in  Appendix  D. 

C.  OVERVIEW 

i  the  chapters  that  follow,  we  provide  background  information  which  we  used  to  pro- 
di  working  change-merging  tool.  Chapter  II  provides  definitions  of  mathematical  con¬ 
structs  used  in  later  chapters.  Chapter  III  provides  information  about  related  work,  some  of 
which  was  accomplished  by  others  before  our  effort  was  started,  and  some  we  have  accom¬ 
plished  during  the  course  of  the  research  effort.  Chapter  IV  provides  a  semantic  model  for 
the  PSDL  computational  model  which  we  used  to  develop  our  algorithm,  and  it  contains  the 
discussions  about  this  dissertation’s  primary  contributions  to  the  state  of  the  art.  Chapter 
V  contains  the  algorithms  used  to  implement  our  tool,  along  with  a  discussion  of  their  cor¬ 
rectness  and  complexity.  Chapter  VI  outlines  the  development  of  the  change-merging  tool 
and  Chapter  VII  provides  our  analysis  of  what  we  accomplished  in  this  effort,  and  some 
future  research  options  in  this  area.  There  are  five  appendices:  Appendix  A  contains  formal 
specifications  for  the  constructs  used  in  our  model,  Appendix  B  contains  details  about  the 
effect  of  PSDL  control  constraints  on  our  model,  Appendix  C  contains  proofs  considered  too 
lengthy  to  be  included  in  the  text  of  the  dissertation,  and  Appendix  D  contains  a  listing  of 
the  PSDL  grammar,  and  Appendix  E  contains  the  program  listings  of  our  implementation. 
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II.  ALGEBRAIC  FOUNDATION  FOR  MERGING 

A.  WHAT  IS  CHANGE-MERGING 

Change-merging  is  a  process  that  allows  different  changes  to  a  software  product  to 
be  combined  using  computer-aided  tools.  The  result  of  this  change-merge  must  contain  the 
differences  between  the  base  version  and  each  input  version,  and  must  be  correct  with  respect 
to  the  method  used;  syntactic  or  semantic.  Syntactic  change-merging  is  performed  on  the 
source  code  of  the  the  input  versions  with  respect  to  the  differences  in  the  syntax  of  each 
version.  Semantic  change-merging  is  performed  on  the  functions  computed  by  the  software 
product  with  respect  to  the  behavior  associated  with  each  input  version.  Semantic  change¬ 
merging  requires  a  solid  mathematical  foundation  to  provide  some  guarantee  of  correctness 
and  engender  confidence  in  a  working  change-merging  system.  As  has  been  pointed  out  in 
much  of  the  previous  work  on  merging,  there  is  a  solid  foundation  for  representing  program 
variations  in  algebra  [Ref.  6, 28, 42].  This  chapter  introduces  and  explains  the  mathematical 
concepts  needed  to  understand  the  work  presented  in  later  chapters.  Section  B  describes 
the  sets  and  partially  ordered  sets,  and  their  relation  to  change-merging.  Section  C  extends 
the  discussion  to  Lattices  and  describes  how  lattices  are  used  in  change-merging.  Section  D 
builds  up  to  Boolean  and  Brouwerian  Algebras  which  are  very  useful  in  performing  change- 
merge  operations. 

B.  SETS  AND  POSETS 

A  set  is  a  collection  of  objects,  called  elements.  Operations  on  sets  include  €  (member¬ 
ship  test),  U  (union),  H  (intersection)  and  —  (difference).  A  partially  ordered  set,  or  posct, 
is  defined  as  follows  [Ref.  16]: 
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Definition  l  PirtiiHy  Ordered  Soto 

./ 

A  nonempty  set  A1  is  said  to  be  a  partially  ordered  set,  or  poset,  provided  that  a  relation 
£  is  defined  on  X ,  satisfying  the  following: 

1.  £  is  reflexive:  x  C  x  for  all  x  €  X; 

2.  £  is  antisymmetric:  xQy  and  yCi  imply  that  x  —  y\ 

3.  Q  is  transitive:  xQy  and  y  Q  z  imply  that  x  Q  z. 

Such  a  relation  C  is  called  a  partial  ordering  of  the  set  X. 

Our  method  of  change-merging  is  performed  on  variations  of  a  PSDL  program.  Changes 
to  PSDL  programs  are  not  always  extensions  of  a  previously  defined  program.  Different 
variations  can  change  a  previous  program  in  different  ways.  Since  these  different  variations 
are  not  always  compatible  extensions  of  earlier  versions,  the  set  of  all  program  variations 
does  not  form  a  completely  ordered  set.  But  since  some  program  variations  are  compatible 
extensions  of  other  programs,  the  set  of  all  program  variations  forms  a  partially  ordered  set, 
with  respect  to  an  approximation  relation,  C. 

Definition  2  Approximation  Relation  for  PSDL  Prototypes 

If  x  and  y  are  two  PSDL  prototypes,  x  approximates  y,  written  xQy,  ify  exhibits  any 
behavior  that  x  exhibits. 

Proposition  1  The  set  of  all  possible  PSDL  prototypes  is  a  poset. 

Proof: 

If  x  and  y  are  PSDL  prototypes,  let  C  be  the  approximation  relation  defined  in  Defini¬ 
tion  2. 

By  Definition  1,  for  the  set  of  all  possible  PSDL  prototypes  to  be  a  poset,  it  must  satisfy 
the  three  conditions,  reflexivity,  antisymmetry ,  and  transitivity. 
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(a)  Clearly  x  C  x,  as  x  certainly  exhibits  its  own  behavior. 

% 

(b)  Let  *  E  y  and  j/Ci.  Then  y  exhibits  any  behavior  that  x  exhibits,  and  x  exhibits 
any  behavior  that  y  exhibits.  Thus  x  =  y. 

(c)  Let  x  Q  y  and  y  Q  x.  Then  y  exhibits  any  behavior  that  x  exhibits  and  possibly 
more,  and  x  exhibits  any  behavior  that  y  exhibits,  so  z  exhibits  any  behavior  that  x  exhibits. 
Thus  x  C  z. 

Therefore  by  (a),  (b)  and  (c),  the  set  of  all  possible  PSDL  prototypes  is  a  poset.  □ 

C.  LATTICES 

A  lattice  ordered  poset  is  a  partially  ordered  set  (L,C)  such  that  for  every  pair  of 
elements,  x,y  €  L,  the  supremum,  sup(x,y),  and  the  infunum,  m/(x,y),  exist  [Ref.  34].  An 
example  of  a  lattice  is  shown  in  Figure  2.1. 

An  algebraic  lattice  is  a  nonempty  set  L  together  with  two  binary  operations,  meet  (n) 
and  join  (U),  which  satisfy  the  following  conditions  for  all  x,  y,  z  €  L  [Ref.  34]: 

(1)  Commutativity:  x  n  y  =  y  n  x  and  x  U  y  s=  y  U  x. 

(2)  Aaaodativity:  x  n  (y  fl  z)  *  (x  n  y)  n  z  and  x  U  (y  U  z)  *  (x  U  y)  U  z. 

(3)  Absorption:  x  fl  (x  LI  y)  =  *  and  x  U  (x  n  y)  =  *. 

(4)  Idempotence:  xflx  =  x  and  rUi  =  i. 

In  the  context  of  merging  pure  program  extensions,  the  meet  (n)  operation  represents 
the  greatest  common  approximation  of  two  programs,  and  the  join  (U)  operations  repre¬ 
sents  the  least  common  extension.  The  greatest  common  approximation  of  two  programs 
represents  the  functionality  common  to  both  programs,  and  the  least  common  extension 
represents  the  union  of  both  of  their  functionalities. 
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Figure  2.1:  An  Example  of  a  Lattice. 

According  to  [Ref.  34],  every  lattice  ordered  set  is  an  algebraic  lattice  if  we  define 
*  n  y  =s  in /(x,  y)  and  x  U  y  =  sup(x ,  y). 

A  distributive  lattice  is  an  algebraic  lattice  for  which  at  least  one  of  the  following 
properties  holds: 

1.  x  n  (y  U  z)  =  (x  n  y)  U  (x  PI  z). 

2.  x  U  (y  n  z)  =  (x  LI  y)  n  (x  U  z). 

An  algebraic  lattice  C  is  complemented  if  for  every  x  E  £  there  is  at  least  one  element 
y  € C  such  that  xUy  =  T  and  xlly  =  1.  We  say  that  y  is  the  i  complement  of  x. 

D.  BOOLEAN  AND  BROUWERIAN  ALGEBRAS 

A  Boolean  Algebra  is  a  complemented,  distributive  lattice  [Ref.  34].  Change-merging 
over  Boolean  algebras  is  done  very  simply  using  set  operations.  A  very  rich  and  well  under¬ 
stood  set  of  laws  is  available  for  the  use  of  Boolean  Algebras. 

A  Brouxucrian  Algebra  is  a  distributive  lattice  with  a  pseudo-difference  operation,  — , 
characterized  by  the  property  x  —  y  C  z  <=>  xCyUz.  This  property  states  that  the 
pseudo-difference  of  two  sets  x  and  y  is  contained  in  the  set  z  if  and  only  if  x  is  contained 
in  the  supremum  of  y  and  z.  A  formal  definition  of  Brouwerian  algebras  follows  [Ref.  39]: 
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Definition  3  Brouwerian  Algebras 

.r 

A  Brouwerian  algebra  is  an  algebra  (L,  U,  fl,  — ,  T)  that  satisfies  the  following  properties: 

(i)  (L,  U,  0)  is  a  lattice  with  a  greatest  element,  T. 

(ii)  L  is  closed  under  — . 

(Hi)  For  all  elements  x,  y,  z  6  L,  the  formulas  x  —  y  C  z  and  x  C  y  U  z  are  equivalent. 

[Ref.  39]  also  provides  the  following  properties  of  Brouwerian  algebras: 

Theorem  1  Let  L  be  a  Brouwerian  algebra  under  U,  fl  and  — .  Then: 

(i)  L  has  a  zero  element,  J.  determined  by  the  formula  _L  =  T  —  T. 

(ii)  L  is  a  distributive  lattice. 

(Hi)  If  x  C  y,  then  x  —  z  Cy  —  z,  z  —  y  C  z  —  x,  and  T  -  y  C  T  —  x. 

(iv)  xCy  4=*  x  —  y  —  J_. 

(v)  x  C  y  U  (x  —  y). 

(vi)  (x  U  y)x  —  y  C  x. 

(vii)  i-2C(iUy)-z. 

(viii)  2U(i-y)  =  2  +  [(zUi)-(zU y)]. 

(ix)  z  -  (x  fl  y)  =  (z  -  x)  U  (z  -  y). 

(x)  (xUy)-2  =  (x-z)U(y- z). 

(xi)  T  -  (T  -  x)  C  x. 

(xii)  T  -  (T  -  (T  -  x))  =  T  -  x. 

(xiii)  T  —  JL  =  T  and  T  -  T  =  J.. 

(xiv)  x  U  (T  —  x)  =  T. 

The  proof  of  this  theorem  is  contained  in  [Ref.  39]. 

Brouwerian  algebras  are  very  useful  in  the  study  of  sets  in  which  the  true  difference 
between  two  elements  is  not  guaranteed  to  exist. 
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E.  SUMMARY 


It  turns  out  that  every  component  of  PSDL  programs  that  can  be  change-merged  can 
be  modeled  using  lattices  or  algebras.  Many  of  the  different  parts  of  PSDL  prototypes  which 
are  merged  separately  do  not  fit  nicely  into  Boolean  algebras,  with  the  exception  of  some 
control  constraints,  so  we  introduced  the  concept  of  Brouwerian  algebras.  Throughout  this 
dissertation,  the  concepts  discussed  in  this  chapter  are  used  to  prove  different  parts  of  the 
change-merging  model  contained  in  Chapters  III  and  IV,  and  considered  in  the  development 
of  the  algorithm  and  implementation. 


III.  RELATED  WORK 


This  chapter  reviews  and  assesses  some  of  the  work  related  to  the  change-merging 
problem  which  has  already  been  accomplished.  Since  change-merging  is  a  relatively  new 
problem,  there  have  been  a  number  of  research  efforts  aimed  at  defining  the  theoretical 
foundations  for  the  problem,  but  not  much  effort  has  been  placed  on  implementing  a  solution 
for  real  programs.  Our  research  effort  is  the  first  to  tackle  a  real-world  problem  and  succeed 
in  providing  a  working  solution.  This  effort  would  have  been  nearly  impossible,  however, 
had  it  not  been  for  the  pioneering  work  reviewed  in  this  chapter. 

A.  TEXT  BASED  MERGING 

The  earliest  work  on  program  merging  relied  on  combining  changes  made  to  the  text 
files  containing  the  source  code  for  the  program  [Ref.  43,  45].  These  early  systems  certainly 
provided  an  advance  to  the  then-current  state  of  the  art,  but  syntax-based  merging  did  not 
prove  useful  in  the  general  case,  as  syntax-based  merging  proved  insufficient  to  provide  any 
guarantee  of  semantic  correctness  [Ref.  6], 

The  first  of  the  text-based  merging  systems  was  introduced  as  part  of  a  software  man¬ 
agement  toolkit  called  the  Revision  Control  System  or  (RCS)  [Ref.  45].  This  system  was 
developed  as  a  way  to  maintain  the  update  history  of  a  file.  The  system  saves  the  initial 
version  of  the  file  when  invoked  for  the  first  time  and,  in  subsequent  invocations,  saves  only 
the  changes  made  to  the  previous  version.  Merging  is  accomplished  through  the  use  of  the 
command  RCSMERGE.  RCSMERGE  tries  to  combine  the  differences  between  two  differ¬ 
ent  changes  to  the  same  base  document  based  on  the  assumption  that  changes  to  disjoint 
portions  of  the  text  are  independent.  Where  it  is  able  to  combine  the  changes,  it  makes 
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the  change  to  the  output  file.  When  it  is  not  able  to  combine  the  differences,  it  prints  the 
respective  piece  of  each  version  ms  m  conflict  in  the  output  file,  so  the  author  can  resolve  it 
manually. 

These  systems  work  well  for  most  text  files  with  small  individual  changes.  For  programs, 
however,  they  do  not  provide  even  a  guarantee  of  syntactic  correctness,  and  in  some  cases 
when  the  changes  are  significant,  the  tool  is  unable  to  match  even  the  parts  that  did  not 
change. 

B.  MERGING  OF  PROGRAM  EXTENSIONS 

In  (Ref.  6],  Berzins  presents  the  first  definitive  work  on  semantic-based  program  merging. 
This  work  is  limited  to  considering  program  extensions,  and  does  not  consider  changes  that 
remove  functionality  from  the  base  program.  It  recognizes  that  program  extensions  can  be 
ordered  using  an  approximation  relation  C.  If  p  is  a  base  program,  and  q  is  an  extension  of 
p.  then  pQq-  That  is  to  say  that  the  functionality  of  q  agrees  with  the  functionality  of  p 
everywhere  p  is  defined,  but  q  may  be  defined  where  p  is  not. 

With  this  ordering  in  mind,  two  programs  p  and  q  can  be  merged  by  finding  the  least 
common  extension  of  p  and  q ,  written  pU  9,  where  p  and  q  are  base  programs  and  pUq  is  the 
merged  program.  He  also  recognizes  that  the  exact  least  common  extension  of  two  programs 
is  not  computable  in  the  general  case,  but  a  safe  approximation  is  sufficient  in  practice. 

Berzins  considers  four  software  domains:  specifications,  functions,  programs  and  data 
types.  These  domains  are  defined  in  Figure  3.1.  All  of  these  domains  are  represented  using 
lattices.  The  following  sections  describe  the  representation  of  these  domains. 


Specification: 
Function : 
Program: 
Data  Type 


Defines  Acceptable  Range  of  Behavior 
Models  Actual  Behavior 
Algorithms  Defining  Partial  Functions 
Set  on  which  Programs  Operate 


Figure  3.1:  Definitions  of  Relevant  Domains 

1.  Functions,  Specifications  and  Programs 

Functions,  specification  and  program  domains  can  all  be  viewed  as  lattices  with 
respect  to  the  approximation  ordering  C-  Each  lattice  contains  the  elements  of  the  domain 
together  with  a  top  element,  T,  representing  an  overconstrained  element,  and  a  bottom 
element,  _L,  representing  an  undefined  element.  The  least  common  extension  of  two  elements, 
x  and  y  can  then  be  defined  in  terms  of  lattice  operations  as  the  least  upper  bound  of  x  and 
y,  denoted  x  U  y.  If  x  and  y  are  compatible,  then  otherwise  x  U  y  =  T. 

2.  Data  Types 

The  lattice  for  a  domain  representing  a  conventional  data  type,  D0,  can  be  defined 
as  a  set  V  =  D0  U{JL,  T},  where  JL  approximates  everything  and  T  is  an  extension  of 
everything.  The  definition  of  the  extension  relation  for  V  is: 

x  C  y  <=>  (J.  =  x)  V  (x  =  y)  V  (y  =  T) 

The  least  upper  bound  of  any  two  unequal  elements  in  this  domain  is  T,  the  overconstrained 
element.  This  model  applies  to  data  types  whose  elements  are  either  completely  defined  or 
completely  undefined.  An  example  of  a  type  that  is  not  covered  by  this  construction  is  a  list 
with  a  component  selector  implemented  using  lazy  evaluation.  Some  components  of  such  a 
list  may  be  well  defined,  while  other  components  may  be  undefined  (i.e.  cause  infinite  loops 
if  they  are  accessed). 
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3.  Analysis 


The  work  presented  in  [Ref.  6]  provides  a  fundamental  basis  for  most  of  the  current 
work  in  semantics-based  program  integration  and  merging.  It  looks  at  programs  in  terms  of 
their  semantic  building  blocks  and  provides  a  theory  describing  how  merging  occurs  at  the 
building  block  level.  This  work  shows  that  computing  a  useful  approximation  to  an  ideal 
merge  is  both  achievable  and  sufficient. 

C.  INTEGRATION  OF  CHANGES  TO  WHILE-PROGRAMS 

In  [Ref.  28],  the  first  semantics-based  algorithm  for  integrating  two  non-interfering 
modifications  of  a  base  program  is  described.  This  integration  algorithm  produces  a  third 
program  which  reflects  both  modifications,  and  uses  program  dependence  graphs  (PDGs)  to 
abstractly  represent  the  programs.  Using  program  slicing ,  it  then  determines  which  portions 
of  the  two  modifications  are  different  from  the  base  program.  Based  on  this  information, 
the  algorithm  uses  a  conservative  approximation  to  determine  if  the  changes  can  interfere. 
If  they  can  not,  the  program  slices  are  combined  into  one  integrated  PDG,  which  is  then 
transformed  into  a  final  version  of  the  integrated  program. 

1.  Program  Dependence  Graphs 

A  PDG  for  a  program  P,  as  described  in  [Ref.  28],  is  a  directed  graph,  Gp,  with 
vertices  representing  statements  in  the  program,  and  edges  representing  control  and  data 
dependencies  between  the  vertices.  There  are  also  two  special  types  of  vertices  in  the  PDG 
which  are  not  program  statements;  an  entry  vertex  and  a  final-use  vertex  for  each  output 
variable.  A  complete  list  of  the  types  of  vertices  is  contained  in  [Ref.  2 8j. 

Using  these  components,  a  PDG  can  be  constructed  for  any  while-program  [Ref.  33]. 
Figure  3.2  shows  an  example  of  a  simple  program  and  its  associated  PDG.  By  analyzing  the 
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parts  of  this  graph  that  affect  a  certain  variable,  we  are  able  to  observe  the  effects  of  a  change 
to  the  program  with  respect  to  that  variable.  This  is  done  using  program  slicing  {Ref.  47]. 


program 
sum  :=  0; 

X  Js  j* 

while  x  <  11  do 
sum  :=  sum  +  x; 
x  :=x+  1; 
od 

end(x^um) 


CONTROL 
LOOP  INDEPENDENT 
DEF-ORDER 
LOOP  CONTROLLED 


Figure  3.2:  Example  of  a  Program  Dependence  Graph  [Ref.  28] 


2.  Program  Slicing 


The  program  slice  of  a  graph  G  with  respect  to  a  vertex  a  is  the  subgraph  of  G 
induced  by  all  vertices  that  can  reach  a  by  way  of  control  ( — >e)  or  flow  ( — ►/)  dependence 
edges,  along  with  the  edges  that  connect  the  vertices. 

V(G/a)  =  {u>G  V(G)  |  «>—.*} 

To  get  the  slice  of  a  graph  G  with  respect  to  one  of  the  output  variables,  say  x, 
merely  take  the  slice  with  respect  to  the  vertex  labeled  FinaUJat{x).  The  slice  is  con¬ 
structed  backward  from  the  finel-uat  vertex,  and  includes  all  control  or  flow  edges  which 
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can  contribute  to  the  final  value  of  *.  Def-order  edges  are  contained  in  the  slice  only  if  the 
vertex  which  observes  the  dependency  is  also  included  in  the  slice.  This  construction  can 
be  extended  to  a  set  of  vertices  S  —  {si,s?, sj  by  taking  the  union  of  the  vertex  and 
edge  sets  of  all  of  the  individual  program  slices.  Figure  3.3  shows  an  example  of  the  slice 
of  the  previous  program  taken  with  respect  to  the  variable  x  at  the  final-use  node  and  the 
corresponding  PDG. 


program 

while  x  <  11  do 

x:=x  +  l; 

od 

end(x) 


CONTROL 

LOOP  INDEPENDENT 

DEF-ORDER 

LOOP  CONTROLLED 


Figure  3.3:  Example  of  a  Slice  of  a  Program  Dependence  Graph  [Ref.  28] 

3.  Integration  Algorithm 

The  integration  algorithm  presented  in  [Ref.  28]  starts  by  creating  program  depen¬ 
dence  graphs  for  each  program  and,  using  program  slicing,  identifies  the  part  of  the  base 
program  which  is  preserved  in  all  three  versions  and  the  parts  of  the  variations  which  are 
different  from  the  base.  The  common  part  of  all  three  versions  is  called  the  preserved  part , 
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and  the  part  of  each  variation  that  is  different  from  the  base  is  called  the  affected  part  of 
that  variation. 

These  three  slices  are  then  combined  into  an  integrated  PDG.  If  the  integrated 
PDG  is  feasible1  and  the  two  variants  do  not  interfere  with  each  other,  then  the  integration 
is  successful.  One  major  problem  identified  in  this  work  is  that  determining  whether  a  PDG 
is  feasible  is  NP-Complete  [Ref.  2$.  The  other  criterion  for  determining  success  is  more 
tractable,  that  of  determining  interference.  This  is  done  by  comparing  the  slices  of  each  of 
the  three  original  versions  against  slices  in  the  merged  version.  If  the  slice  of  the  merged 
version  with  respect  to  the  affected  parts  of  each  modification  is  the  same  as  the  slice  of  that 
modification  with  respect  to  its  affected  parts,  and  the  slice  of  merged  version  with  respect 
to  the  preserved  part  is  the  same  as  the  base  version  with  respect  to  the  preserved  part,  then 
the  versions  do  not  interfere,  and  a  successful  integration  is  possible. 

The  work  in  [Ref.  28]  is  supported  by  three  theorems;  the  slicing  theorem,  the 
equivalence  theorem  and  the  integration  theorem.  The  slicing  theorem  states  that  when 
given  the  same  input  and  starting  state,  a  slice  of  a  program  that  halts  produces  precisely 
the  same  output  as  the  program.  The  equivalence  theorem  states  that  if  two  programs  have 
equivalent  PDGs,  then  the  programs  are  themselves  equivalent.  The  integration  theorem 
states  that  if  M  is  the  result  of  a  successful  integration,  then  M  halts  on  any  initial  state 
on  which  the  three  input  versions  halt,  and  M  correctly  preserves  the  meaning  of  each 
modification  to  the  base. 

4.  Meaning  Functions 

Meaning  functions  [Ref.  33]  represent  the  semantic  meaning  of  a  program  as  map¬ 
pings  from  states  to  states.  These  state  changes  are  represented  as  sets  of  pairs  including  an 
initial  state  and  the  corresponding  final  state(s).  In  [Ref.  10],  Berzins  provides  a  theoretical 
lA  program  dependence  graph  is  feasible  if  it  is  a  PDG  for  a  program. [Ref.  2$ 
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fcaAtiw  for  merging  ample,  imperative  programs  using  their  meaning  functions.  This 
theory  uses  the  notion  that  program  variations  can  be  viewed  as  partial  functions  modeled 
using  a  powerset  lattice.  Since  a  powerset  lattice  is  equivalent  to  a  Boolean  algebra,  normal 
set  operations,  U,  D  and  —  can  be  used  to  reason  about  these  program  variations. 

This  theory  shows  that  a  change  transformations  from  a  base  program  /  to  a 
variation  g,  A[f,  <7],  can  be  applied  to  a  second  variation  h,  A[/,  g](h)  with  precisely  the 
same  results  as  if  the  change  from  f  to  h  were  applied  to  g,  A[f,h](g).  This  is  very  useful 
in  change-merging,  as  it  demonstrates  that  independent  updates  to  a  common  base  version 
g  of  a  software  product  and  subsequently  change-merged  without  regard  for  the  order  in 
which  they  were  accomplished.  As  long  as  the  changes  made  are  compatible,  the  results  in 
terms  of  the  meaning  functions  are  the  same.  It  does  show,  however,  that  the  change-merged 
program  does  not  necessarily  have  to  be  similar  to  the  input  programs. 

The  meaning  functions  for  the  programs  shown  in  Figure  3.4  are  as  follows: 
m(B)  »  (x  >  0  -*  {((*,  y),  (x,  1))}  |  x  <  0  -►  {((x,  y),  (x,  -1))}) 
m(A)  *  (x  >  0  -►  {((x,y),(x,  1))}  |  x  <  0  {((*,y),(*,0))}) 

m(C)  =  (x  >  0  -♦  {((x,y),(x,x))}  |  x  <  0-»  {((x,y),(x,-l))}) 

These  three  versions  are  merged  using  their  meaning  functions  as  follows  [Ref.  10}: 
m(M)  =  m(A[B]C)  =  m(A)[m(B)]m(C) 2 

=  (m(A)  -  m(£))  U  (m(A)  n  m(B))  U  (m(C)  -  m(B)) 

-  (x  >  0  -  {((x,y),  (x,  1))}  -  {((x,y),  (x,  1))}  | 

*  <  0  -  {((x,y),(*,0))}  -  {((x,y),  (x,  — 1))}) 

U(x  >  0  — »  {((x,  y),  (x,  1))}  fl  {((x,y),  (x,x))}  | 

*  <  0  {((x, y),  (x, 0))}  fl  {((x, y),  (x,  -1))}) 

U(x  >  0  — »  {((x,y),(x,x))}  -  {((x,  y),  (x,  1))}  | 

*  <0->  {((*,y),(x,-l))}-{((x,y),(x,-l))}) 

*The  noUtke  A[B]C  will  be  introduced  in  Section  D.l 
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«(x>0->{}|x<0-.  {((x, y), (x,0))} 

U(x  >  0  — *  {((x,v),(M))}  I  x  <  0  {}) 

U(x  >  0  — *  {((x,»),(x,x))  |  X  /  1}  I  x  <  0  -•  {}) 

»  (*  >  0—  {((*.»).(*.*))}  I  *  <  0  ->  {((x,»),(x,0))}) 
=  m(if  x  >  0  then  y x  else  y  :=  0)  =  m(M) 


Base  version  B:  if  x  >  0  then  y  :=  1  else  y  :=  — 1  fi 

First  change  version  A:  if  x  >  0  then  y  :=  1  else  y  :=  0  fi 

Second  change  version  C:  if  x  >  0  then  y  :=  x  else  y  :=  — 1  fi 

Figure  3.4:  A  Program  and  Two  Variations  [Ref.  10] 

5.  Analysis 

The  work  presented  in  this  section  shows  that  a  method  can  be  developed  for 
integrating  real  programs.  The  work  contained  in  (Ref.  28,  29,  48]  illustrates  a  method  for 
integrating  programs  in  a  simple  imperative  programming  language  that  has  been  developed 
and  works.  This  demonstrates  that  a  practical  method  is  possible  for  imperative  programs, 
but  falls  short  of  providing  a  method  which  is  useful  to  solve  any  real  world  problems.  In 
particular,  the  method  fails  to  provide  any  sort  of  conflict  location  or  resolution.  If  a  conflict 
is  detected,  then  it  is  reported  to  the  user,  and  the  integration  fails.  It  is  up  to  the  user  to 
determine  the  nature  of  the  conflict  and  how  it  should  be  resolved.  Our  methods  address 
these  problems  as  shown  in  the  next  section  and  in  Chapter  TV. 

D.  CHANGE-MERGING  OF  PSDL  PROGRAMS 

In  [Ref.  20],  an  initial  attempt  at  developing  a  model  for  change-merging  PSDL  pro¬ 
grams  is  presented.  Although  crude,  this  model  provides  us  with  an  important  part  of  the 
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sparitsatWi  rhangamarfing  mo<iel,  and  insight  into  the  current  effort  defined  in  subsequent 
chapter*. 


1.  Change-Merge  Operation 

This  change-merge  operation  is  defined  by  the  operation  A[B]C,  where  A ,  B  and  C 
are  sets  of  pairs  representing  the  functionality  of  three  different  versions  of  a  PSDL  program. 
The  operation  A[B]C  was  initially  introduced  by  Berzins  in  [Ref.  9]  and  is  defined  as: 

A[B]C  «  (A  -  B)  U  (A  n  C)  U  (C  -  B) 

where  n,  LI  and  —  represent  the  greatest  common  approximation,  least  common  extension , 
and  semantic  difference  respectively,  between  two  programs. 

The  set  of  all  PSDL  programs,  together  with  a  T  and  X,  forms  a  lattice  using  the 
relation  approximates  [Ref.  20].  If  A  is  an  extension  of  B,  then  we  say  that  B  approximates 
A,  written  B  C  A.  The  T  element  in  the  lattice  is  an  extension  of  every  PSDL  program, 
and  the  X  element  approximates  all  PSDL  programs.  For  example  consider  the  lattice  in 
Figure  3.5.  In  this  example,  O  and  P  are  extensions  of  A  and  A  approximates  both  O  and 
P.  P  and  Q  are  both  extensions  of  B  and  B  approximates  both  P  and  Q.  P  is  a  common 
extension  for  both  A  and  B.  In  fact,  P  is  the  least  common  extension  of  A  and  B. 
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The  least  common  extension  of  two  PSDL  programs,  AUB ,  is  the  smallest  possible 
PSDL  program  P  such  that  A  C  P  and  B  C  P,  and  represents  the  union  of  the  functionalities 
found  in  both  A  and  B.  In  Figure  3.5,  P  is  the  least  common  extension  of  A  and  B.  The 
greatest  common  approximation  of  two  PSDL  programs,  PnQ,  is  the  largest  possible  PSDL 
program  B  such  that  BQP  and  B  C  Q,  and  represents  the  common  functionality  found  in 
both  P  and  Q.  In  Figure  3.5,  B  is  the  least  common  extension  of  P  and  Q.  The  semantic 
difference  between  two  programs,  A  —  B,  represents  the  functionality  found  in  A,  but  not  in 
B.  The  semantic  difference  exists  if  the  lattice  is  a  Boolean  algebra,  and  a  pseudo-difference 
can  be  defined  if  the  lattice  is  a  Brouwerian  algebra. 

It  has  been  shown  that  the  least  common  extension  of  two  programs  is  not  com¬ 
putable  in  the  general  case  [Ref.  6].  In  [Ref.  20],  we  demonstrated  that  an  approximation  that 
is  computable  is  sufficient  to  provide  a  useful  change-merge  for  most  cases.  The  following 
sections  outline  the  model  defined  in  [Ref.  20]. 

2.  Interfaces 

The  interface  of  a  PSDL  operator  P  is  the  definition  of  the  operator’s  external 
contacts.  It  defines  Ip,  the  set  of  inputs  expected  by  the  operator,  Op,  the  set  of  outputs 
that  can  be  expected,  and  in  the  case  of  generic  templates,  GNp,  the  set  of  generic  param¬ 
eters  used  to  instantiate  the  prototype.  Ip,  Op,  and  GNp  are  all  ordered  sets  (sequences). 
The  interface  may  also  contain  a  set  Stp ,  of  internal  state  variables,  a  set  Ep,  of  possible 
exceptions,  and  a  maximum  execution  time  constraint  that  is  met  by  the  program.  Stp  and 
Ep  are  sets. 


a.  Sequences 

Sequences  are  a  significant  building  block  for  many  programming  languages, 
including  PSDL.  A  sequence  is  a  totally  ordered  collection.  Since  the  order  of  the  collection 
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is  significant,  any  change  made  to  the  sequence  is  an  incompatible  change  and  creates  a 
sequence  which,  is  neither  an  approximation  nor  an  extension  of  the  original  sequence/  A 
correct  mathematical  reprer  atation  for  a  sequence  would  be  a  flat  lattice,  like  the  one  in 
Figure  3.6.  This  means  that  the  only  approximation  for  the  sequence  is  the  undefined 
sequence,  X,  and  the  only  extension  of  the  sequence  is  the  unconstrained  set,  T,  and  the 
greatest  common  approximation  of  any  two  sequences  is  the  undefined  element,  X. 


Figure  3.6:  A  Flat  Lattice  Representation  for  a  Sequence 

(1)  Input  and  Output.  Input  and  Output  interfaces  are  sequences  of  input 
and  output  streams.  The  order  of  these  sequences  is  significant  because  actual  parameters 
are  associated  with  formal  parameters  based  on  the  order  in  which  they  appear.  In  change¬ 
merging  I  a,  Ib ,  and  I  Bate  into  Im,  any  change  between  the  interface  sequence  of  the  base 
version  and  the  two  modified  versions  is  significant,  and  must  be  preserved  in  the  change- 
merged  version.  The  change-merged  sequence  of  inputs,  or  outputs,  is  determined  by  the 
following  rules: 

1.  If  both  of  the  modified  versions  have  the  same  interface  sequence  as  the  base, 
then:  Im  =  I  Bate- 

2.  If  one  of  the  two  modified  versions,  say  I  a,  is  the  same  as  the  base,  and  Ib  is 
not,  then:  Im  —  Ib- 

3.  If  all  three  versions  are  different  from  each  other,  then:  Im  =  T. 
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The  first  situation  is  the  case  in  which  no  changes  were  made  between  the 
inputs  of  the  Base  and  the  two  modifications.  In  this  case,  the  change-merged  version  should 
have  all  of  the  same  inputs,  or  outputs.  The  second  situation  is  the  case  in  which  only  one  of 
the  modifications  changed  from  the  base.  In  this  case,  the  change  from  the  base  is  significant 
and  must  be  preserved  in  the  change-merged  version.  The  third  situation  is  the  case  where 
both  of  the  modifications  changed  from  the  base.  The  result  is  a  conflict  because  there 
is  no  proper  PSDL  specification  that  is  consistent  with  both  modifications.  The  result  of 
a  change-merge  which  produces  a  conflict  for  this  situation  would  be  an  input  declaration 
which  contains  a  T  where  the  input  stream  declarations  would  be. 

The  type  declarations  of  the  streams  also  have  to  be  merged.  Because  the 
types  are  significant,  any  change  to  the  type  declaration  must  be  preserved  in  the  merged 
version.  Types  are  also  change-merged  using  a  flat  lattice  structure.  Figure  3.7  contains  an 
example  of  a  change-merge  on  Input  Sets. 


SBa~  =  INPUT 

x :  integer, 
y :  real 
OUTPUT 
w  : integer, 
z  :  string 


SA  =  INPUT 

x  : integer 
OUTPUT 
w :  integer, 
t :  integer, 
z  :  string 

SM  =  INPUT 

x : integer 
OUTPUT 
T 


SB  =  INPUT 

x : integer, 
y  :  real 
OUTPUT 

w  :  integer 


Figure  3.7:  Example  of  a  Change-Merge  on  Input  Sets  [Ref.  20] 
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(2)  Generic  Parameters.  The  Generic  interface  is  contained  only  in  template 
operators  and  PSOL  type  specifications.  Template  operators  are  operators  in  the  Software 
Base  used  to  instantiate  software  components.  Change-merging  generic  parameters  is  similar 
to  change-merging  input  and  output  parameters  with  the  exception  that,  in  addition  to 
value  parameters,  generic  parameter  sequences  may  also  contain  operator  parameters  and 
type  parameters.  Changes  to  generic  sequences  follow  the  same  rules  as  Input  and  Output 
sequences.  Figure  3.8  shows  an  example  of  a  change-merge  operation  on  generic  parameters. 


GNBmM  =  GENERIC 
<1  :  type, 

<2 :  type , 

ol  :  operational,  i2  :  tl,ol  :  t2], 
t>l  :  integer 


GNa  =  GENERIC 
tl  :  type, 
i3  :  type, 

o2  :  operational  :  tl,  ol  :  t3], 
vl  :  integer 

GNm  =  GENERIC 


GNb  =  GENERIC 
tl  :  type, 


f2  :  type, 

ol  :  operational,  t'2  :  tl,ol  :  t2], 
vl  :  integer 


tl :  type, 
t3 :  type, 

o2  :  operational  :  tl,ol  :  t3], 
vl :  integer 


Figure  3.8:  Example  of  a  Change- Merge  on  Generic  Parameters  [Ref.  20] 


b.  Sets 


Sets  are  modeled  using  a  “Powerset  Lattice”  as  shown  in  Figure  3.9,  and  thus 
more  freedom  can  be  exercised  in  change-merging  them.  Change-merge  operations  do  not 
follow  the  same  rules  for  sets  as  for  sequences. 
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\a,o,  cj 


{} 

Figure  3.9:  A  Powerset  Lattice  Representation  for  a  Set  Containing  Three  Elements 

(1)  States.  State  variables  differ  from  input  and  output  variables  in  that, 
abstractly,  they  are  tuples,  containing  a  name,  a  type  and  an  initial  value.  As  the  set 
of  state  variables  is  unordered  and  invisible  to  the  rest  of  the  program,  the  state  set  can 
be  increased  or  decreased  without  affecting  the  parts  of  the  program  outside  the  modified 
component.  In  change-merging  state  variable  sets,  the  operations  n,  U,  and  —  are  equivalent 
to  the  corresponding  set  operations,  U,  H  and  — .  The  third  part  of  the  tuple,  the  initial 
value,  requires  an  additional  check  in  the  change-merging  process.  These  initial  values  are 
ordered  using  a  flat  lattice,  because  they  are  ordinary  data  values.  The  initial  value  of  a 
change-merged  state  variable  follows  the  same  change-merging  rules  as  input  and  output 
variables.  If  all  three  versions  have  different  initial  values  for  the  same  state  variable,  then 
the  change-merged  version  contains  a  T  in  the  place  where  the  initial  value  is  assigned.  If 
only  one  of  the  modifications  assigns  a  different  initial  value  than  the  base  version,  then  the 
change-merged  version  contains  the  initial  value  of  the  one  that  was  different. 

(2)  Exceptions.  The  exceptions  interface  is  a  list  of  identifiers  which  denote 
exception  values  which  may  be  returned  by  the  operator.  Consequently  n,  U,  and  —  can  be 
interpreted  as  the  corresponding  set  operations,  U,  D  and  — .  Exceptions  that  appear  in  one 
or  both  of  the  modified  versions,  and  not  in  the  base,  appear  in  the  change-merged  program. 
Exceptions  that  appear  in  the  base  and  do  not  appear  in  at  least  one  of  the  modifications 
are  not  included  in  the  change-merged  program. 
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(3)  Maximum  Execution  Time.  Maximum  Execution  Time  (MET)  is  the 
only  timing  constraint  that  appears  in  PSDL  specifications.  MET  is  the  maximum  CPU 


time  that  an  operator  can  use  to  perform  its  assigned  task.  Change-merging  two  MET 


constraints,  and  <3,  can  be  done  as  follows: 


<iUi3  =  mm(ti,ia) 

t]  nt)  = 

ti—ti  =  if  <3  <  ti  then  oo  else  U 

T  =0 

±  —  oo 


Proposition  2  The  set  of  METs  form  a  Brouwerian  Algebra 


Proof: 

Let  Ad  be  the  set  of  all  possible  METs. 

We  must  show  that  Ad,  U,  n  is  a  distributive  lattice,  that  Ad  is  closed  under  — ,  and 

that 

Va,b,c£  M,a  —  i<c«=>o<  (6U c). 

1.  (Ad,  U,n)  is  a  distributive  lattice: 

Clearly,  a  U  b  and  alii  exist  for  any  a, b  €  Ad,  and  the  reflexive,  antisymmetric,  and 
transitive  properties  hold,  so  (Ad,  U,n)  is  a  lattice. 

Ad  is  distributive:  Let  a,  6,  c  €  Ad.  We  urn  a  table  to  illustrate: 


a  n  (b  U  c) 

(o  n  b)  u  (a  n  c) 

a<b<c 

b 

6 

a  <c<b 

e 

c 

b<a<c 

a 

a 

b<c<a 

a 

a 

e<a<b 

a 

a 

c<b<a 

a 

a 

FYom  the  table  it  is  easy  to  see  that  Ad  is  distributive. 

2.  Ad  is  closed  under  — : 

Since  a  —  b  is  always  either  o  or  oo  for  any  a  and  b.  M  is  certainly  closed  under  — . 
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3.  For  air  a,b,c  €  M,  a  —  b<  e  •<*«>  a  <  (6LJ  c): 

Assume  a  —  b  <  c.  Then,  a  <  6,  since  otherwise,  a  —  b  =  oo.  Since  a  <  b,  then  a  <  c. 
Thus,  a  <  (b  U  c). 

Now,  assume  a  <  (b  U  c).  Then  a  <  b  and  a  <  c,  and  a  —  b  =  a.  Thus  a  —  b  <  c. 

Therefore,  Ad  is  a  Brouwerian  Algebra. 

3.  Functionality 

The  functionality  of  an  operator  specification  is  a  description  of  the  behavior  of  an 
operator.  It  consists  of  a  set  of  keywords,  an  informal  description,  and/or  a  formal  descrip¬ 
tion.  Through  the  use  f  words,  the  operator  can  be  distinguished  from  other  operators 
in  the  database  during  the  retrieval  process.  Informal  text  descriptions  are  provided  for  use 
by  the  engineer.  Formal  axiomatic  descriptions  are  provided  to  support  automatic  retrieval. 

The  set  of  keywords  can  be  change-merged  using  the  appropriate  set  operations, 
U,  n,  and  — .  The  informal  description  is  a  sequence  and  must  be  changed-merged  using 
the  same  method  described  for  input  and  output  parameters.  Formal  descriptions  can  be 
change-merged  using  the  Boolean  algebra  structure  of  the  logic  in  which  they  are  expressed: 

xUy  =  xVy 
x  n  y  =  xAy 
x  —  y  =  x  A  -»y 

4.  Data  Flow  Graphs 

In  [Ref.  20],  a  PSDL  implementation  graph  for  an  operator  A  is  viewed  as  a  graph 
Da  s  {0,L}t  where  O  is  a  set  of  vertices  that  represent  the  component  operators  of  A , 
including  the  constant  operator  EXT  representing  external  contacts,  and  where  L  is  a  set  of 
links  (labelled  edges)  which  represent  the  data  streams  entering  and  leaving  the  elements  of 
O.  The  labels  for  the  links  are  the  names  of  the  data  streams  they  represent. 


The  change-nmging  operation  on  PSDL  data  flow  graphs  is  defined  in  terms  of  a 
bipartite  graph  Ba  *  {V, 5,  LI, LO},  where  V  is  the  set  of  operators  in  DA,  5  is  a  set  of 
vertices  which  represent  the  data  streams  of  operator  A ,  LI  is  a  set  of  edges  from  a  stream 
vertex  to  an  operator  vertex,  representing  input  links,  and  LO  is  a  set  of  edges  from  an 
operator  vertex  to  a  stream  vertex,  representing  output  links. 

Change-merging  the  data  flow  diagrams  is  done  by  change-merging  the  graphs 
CjitM,  Ga  and  Gb  by  subsets  V,  S,  LI  and  LO.  The  operations  LI,  n,  and  —  can  be 
interpreted  as  the  corresponding  operations  U,  H,  and  — .  This  change-merge  is  accomplished 
using  the  following  equation: 

Gu  =  [Ga  —  £?bmc]  u  l Ga  n  Gb]  U  [Gb  —  Gb««] 

This  equation  defines  a  structural  or  syntactic  change-merging  operation  that  does  not  nec¬ 
essarily  correspond  to  a  semantic  change-merging  operation. 

The  greatest  common  approximation  is  obtained  for  the  Base  and  the  two  mod¬ 
ifications  by  taking  the  intersection  on  all  components  of  the  graph.  Then  these  common 
components  are  added  to  the  disjoint  components  of  each  modification  by  subtracting  out 
the  parts  of  the  two  modifications  which  are  also  in  the  base.  This  operation  preserves  the 
parts  of  the  program  common  to  all  the  versions,  while  ensuring  that  significant  changes 
made  by  the  two  modifications  are  included  in  the  change-merged  graph. 

This  method  of  change-merging  the  implementation  graph  of  a  PSDL  program 
fails  to  adequately  consider  the  semantic  effects  of  the  changed  modifications,  as  does  the 
approximate  method  shown  later  in  this  chapter.  Although  these  methods  produce  a  change- 
merge  that  is  useful  in  some  cases,  they  are  not  nearly  as  useful  as  the  slicing  method 
described  in  Chapters  IV  and  V. 
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5.  Data  Streams  and  Control  Constraints 


a.  Data  Streams 

A  set  of  data  stream  declarations  DSa,  defines  local  data  streams  that  are  used 
only  within  the  implementation  of  a  composite  operator,  A,  and  that  are  not  defined  in  the 
specification.  The  order  in  which  the  declarations  appear  is  not  significant.  They  have  the 
same  structure  as  exception  declarations,  and  can  be  change-merged  using  the  same  rules. 
If  a  stream  appears  in  DSp,m  then  it  appears  in  DSu  if  and  only  if  it  appears  in  both  DSa 
and  DSb •  If  a  stream  does  not  appear  in  DSb***  then  it  appears  in  DSu  if  and  only  if  it 
appears  in  at  least  one  of  the  sets  DSa  &nd  DSb-  These  rules  are: 


x  €  DSb**  A 
x  €  DSb**  A 
€  DSb**)  A 
*’(*  €  DSb**)  A 


x  €  DSa  A  *  €  DSb 
-*(x  €  DSa  A  x  €  DSb) 
(x  €  DSa  V  x  €  DSb) 
-•(x  €  DSa  V  x  €  DSb) 


x  €  DSm 
“•(*  €  DSm) 

x  6  DSm 

-'{x  €  DSm) 


The  type  declarations  of  data  streams  are  also  significant,  as  with  Input  and 


Output  Streams,  and  changes  to  those  declarations  must  be  preserved  in  the  merged  version. 
The  type  declarations  can  be  merged  using  a  fiat  lattice  structure  just  as  the  Input  and 
Output  streams  are  merged. 


b.  Control  Constraints 

Control  constraints  are  a  set  of  pre-conditions,  which  control  the  firing  of  par¬ 
ticular  components,  and  post-conditions,  which  filter  the  output  provided  by  those  compo¬ 
nents.  The  control  constraints  appear  in  the  change-merged  operator  according  to  the  same 
rules  as  the  data  stream  definitions.  Any  control  constraint  that  appears  in  all  three  input 
versions  in  exactly  the  same  way  appears  in  the  change-merged  operator  without  change. 
Any  constraint  which  appears  in  one  or  both  of  the  modifications,  but  not  in  the  base, 
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appears  unchanged  as  long  as  the  conditions  of  the  constraint  are  the  same.  Changes  in  con- 

m< • 

ditions  are  handled  differently  depending  on  the  type  of  constraint.  Input  and  output  guards, 
conditional  exceptions,  “TRIGGERED  IF",  “OUTPUT  IF",  “EXCEPTION  IF",  and  timer 
operations  have  logical  predicates  as  conditions.  Timer  operations  are  not  change-merged 
as  straightforwardly  as  other  predicate  constraints.  Different  operations  exist  for  different 
activities.  Start,  stop,  and  reset  are  the  three  timer  operations  used  in  PSDL.  The  timer 
operations  affect  the  state  of  the  timer.  The  start  and  stop  operations  affect  the  run  state  of 
the  timer,  and  the  reset  operation  affects  the  value  state  of  the  timer.  The  reset  operation 
is  thus  independent  of  the  others,  and  can  be  merged  independently.  If  a  reset  operation 
appears  in  all  three  versions,  or  appears  in  at  least  one  of  the  modifications,  but  not  in  the 
base,  then  it  appears  in  the  changed  merged  version  as  well.  The  start  and  stop  operations 
must  be  change-merged  using  a  flat  lattice  ordering  relation,  as  with  inputs  and  outputs. 
The  predicates  that  accompany  the  control  constraints  are  change-merged  according  to  the 
usual  rule,  A\Base\B  —  {A  —  Base) U(AnB)U(B  —  Base),  where  the  operations  n,  U,  and 
—  are  it  er preted  as  follows: 


aU6  =*•  a Vi 
arU  s=>  a  Ah 
a  —  b  =>  a  A ->b 

The  constraints  “PERIOD",  “FINISH  WITHIN",  “MAXIMUM  RESPONSE 
TIME",  and  “MINIMUM  CALLING  PERIOD"  have  integer  values  as  conditions.  These 
values  are  ordered  using  a  flat  lattice  and  can  be  change-merged  as  follows.  For  “PERIOD" 
constraints,  if  the  value  is  the  same  in  all  three  input  versions,  then  it  appears  unchanged 
in  the  merged  version.  If  it  is  different  from  the  base  in  one  of  the  modifications  and  the 
same  as  the  base  in  the  other  modification,  then  the  change  must  be  preserved  and  the  value 
appearing  in  the  modification  where  it  is  different  appears  in  the  merged  version.  If  all  three 
versions  have  different  values  for  the  period,  then  a  ±  or  undefined  value  appears  in  the 
merged  version,  indicating  an  unresolvable  conflict.  “FINISH  WITHIN"  and  “MAXIMUM 
RESPONSE  TIME"  constraints  are  upper  bounds  and  can  be  change-merged  using  the 
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same  method  described  for  "MAXIMUM  EXECUTION  TIME”.  "MINIMUM  CALLING 

PERIOD”  is  e  lower  bound  and  two  MCP  constraints,  t\  and  ta,  can  be  change-merged 

using  the  equations  shown  below: 

tiU*a  *  maz(ti,t9) 
t,nt,  m  min(t|,ta) 

—  <s  *  if  >  ti  then  oo  else 
T  *  0 
«L  as  00 

Proposition  3  The  set  of  all  MCPs  form  a  Browoerian  Algebra 
Proof:  See  the  proof  of  Proposition  2. 

6.  Analysis 

The  work  presented  in  [Ref.  20]  was  a  first  look  at  providing  a  change-merging  ca¬ 
pability  for  PSDL  prototypes.  It  explored  some  critical  issues  in  the  problem  and  provided 
valuable  information  for  work  presented  later  in  this  dissertation.  The  work  on  change¬ 
merging  specifications  has  proven  to  be  very  valuable  and  remains  virtually  unchanged  in 
the  current  model.  Only  the  parts  of  the  model  concerning  tuning  constraints  have  been 
improved  in  the  current  model.  The  work  on  change-merging  implementations  was  unsuc¬ 
cessful  in  providing  a  useful  method.  The  next  sections  provide  a  look  at  an  improvement 
over  this  method. 

E.  CHANGING  PSDL  PROTOTYPES 

In  [Ref.  21],  another  attempt  at  formulating  a  model  for  representing  PSDL  implemen¬ 
tations  is  explored.  In  this  model,  PSDL  prototypes  can  be  considered  iterative  versions 
of  a  software  system.  If  5  is  the  intended  final  version  of  the  software  system,  then  each 
successive  iteration  of  the  prototype  can  be  viewed  as  an  element  of  a  sequence  Si  where 
limj—oo  Si  se  S. 
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1*  Prototyp—  a m  Graphs 


Each  prototype  implementation  5j  is  modeled  as  a  graph  G\  —  ( Vj ,  E[,  Cj),  where: 


e  Vj  is  a  set  of  vertices.  Each  vertex  can  be  an  atomic  operator  or  a  composite 
operator  modeled  as  another  graph. 

e  Ej  is  a  set  of  data  streams.  Each  edge  is  labelled  with  the  associated  variable 
name.  There  can  be  more  than  one  edge  between  two  vertices.  There  can  also 
be  edges  from  an  operator  to  itself,  representing  state  variable  data  streams. 

e  C|  is  a  set  of  timing  and  control  constraints  imposed  on  the  operators  in  version 
i  of  the  prototype. 

2.  Changes  to  Graphs 


The  prototype  designer  repeatedly  demonstrates  versions  of  the  prototype  to  users, 
and  designs  the  next  version  based  on  user  comments.  The  change  from  the  graph  repre¬ 
senting  the  ith  version  of  the  prototype  to  the  graph  representing  the  (i  +  l)st  version  can 
be  described  in  terms  of  graph  operations  by  the  following  equations: 


•  <Si+i  =  (M+ii  El+i,  C|+i)  —  Si  +  A5j 

•  ASi  as  (Vi4j,  VRi,  EA\,  ER\ ,  CA\,  CR{)  where: 


••  V5+1  —  Vj  =  VA\:  The  set  of  vertices  to  be  added  to  5j. 

••  Vj  —  Vj+l  =  VR\:  The  set  of  vertices  to  be  removed  from  5j. 

••  Ej+1  -£js  EA\:  The  set  of  edges  to  be  added  to  S\. 

••  E\  —  -Ej+i  ss  ERl\  The  set  of  edges  to  be  removed  from  S\. 

••  Cj+i  —  Cj  =  CA\:  The  set  of  timing  and  control  constraints  to  be  added  to 

Si. 


••  Ci  —  Cj+i  =  CR\:  The  set  of  timing  and  control  constraints  to  be  removed 
from  5j. 
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5i+i  *  5j  +  A 5j  is  defined  in  terms  of  the  individual  components  of  5|+i  as  follows: 

M+i  =  MU  VAi  -  VHj 

£41  =  E\  U  EA\  —  2£/Zj 
Ci+1  =  Cj  U  CMj  —  CRi 

Hie  following  figures  show  an  example  of  a  change  made  to  a  composite  operator  in 
PSDL.  Figure  3.10  contains  a  graph  representation  for  a  composite  operator  Opl  consisting 
of  4  vertices  and  6  data  streams.  Figure  3.11  shows  a  change  to  be  applied  to  Opl  to  produce 
Op2.  Figure  3.12  shows  a  graph  representation  of  Op2,  the  result  of  applying  the  change  to 
Opl. 


Opl  -  {VuEi,Ci} 

M  =  {A,B,C,D} 

Et  «  {(XI :  EXT  -»  A),  (X2  :  A  -*  B),  (X3  :  A  -►  C),  (X4  :  B  -*  D), 
(X5  :  C  ->  D),  (X6 :  D ->  EXT)} 

Ci  *  {max-ezccJimc(B,  100ms)} 


Figure  3.10:  Example  of  a  composite  operator  in  PSDL 
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AAOpl  =  {VRa,VAa>EAa,ERa,CAa,CRa} 

VAa  =  { £7 } 

VRa  =  {C} 

EAa  =  {(*3  :  A  -*  £),(.X7  :  E  -»  Z))} 

£7£x  =  {(AT3  :A-+C),(X5:C-+  D)} 

CAa  =  {/o<enq/(X7,  £7,  Z?,  50ms)} 

=  {} 


Figure  3.11:  Example  of  a  change  made  to  a  composite  operator  in  PSDL 
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Op2  =  {%,£?,  C?} 

H  =  {A,B,D,E} 

Et  =  {(JSC1:EAT-»>1),(A’2:A-+B),(^3:i4-»E),(X4:B-Z)), 
(X7  :  £7  -►  D),  (X6:D->  EXT)) 

Ci  —  { maxjtxecJLimt{B ,  100ms),  latency(X  7,  £7,  Z7, 50ms)} 


Figure  3.12:  Example  of  the  changed  operator 
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F.  AN  APPROXIMATE  METHOD  FOR  CHANGE-MERGING 
PSDL  PROTOTYPES 

1.  Method 

In  [Ref.  21,  23,  25],  an  approximate  method  for  change-merging  PSDL  prototypes 
is  explored.  This  method  is  useful  in  providing  a  rough  approximation  to  the  ideal  change- 
merge,  but  was  abandoned  in  favor  of  the  more  useful  (and  provably  correct)  slicing  method 
[Ref.  23,  24].  It  is  induded  to  record  the  effort  expended  in  this  endeavor. 

Recall  the  merging  function  introduced  in  [Ref.  9j,  and  reintroduced  in  section  D: 

M  *  A[B]C  s=  (A  -  B)  U  (A  n  C)  U  (C  -  B). 

If  the  semantic  function  of  a  program  is  represented  as  a  set  of  pairs,  then  two  compatible 
modifications  of  a  semantic  function  can  be  merged  using  this  equation. 

In  this  equation,  the  union,  intersection  and  difference  operations  are  defined  as 
normal  operations  on  sets.  The  difference  operation,  (A  —  B)  for  example,  yields  the  part 
of  the  function  present  in  the  modification,  but  not  in  the  base  version.  The  intersection 
operation  yields  the  part  of  the  function  preserved  from  the  base  version  in  both  modifi¬ 
cations.  This  model  preserves  all  changes  made  to  the  base  version,  whether  extensions  or 
retractions.  In  this  model,  two  changes  conflict  if  the  construction  produces  a  relation  that 
is  not  a  single  valued  function. 

In  this  section,  we  outline  an  approximate  method  for  merging  prototypes  using 
the  change  model  described  in  the  previous  section  and  the  above  definition.  This  method  is 
approximate,  in  the  sense  that  the  change  merging  construction  is  applied  to  the  structure 
of  a  PSDL  program  rather  than  to  the  mathematical  function  it  computes.  This  method 
is  simple,  corresponds  to  common  programmer  practice,  and  produces  semantically  correct 
results  most  of  the  time. 
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The  approximate  method  can  be  understood  as  follows.  All  PSDL  implementations 

.w 

are  graphs,  whose  structure  roughly  models  their  functionality.  We  have  represented  these 
graphs  using  sets.  Different  variations  of  a  prototype  are  the  results  of  different  changes 
being  applied  to  a  common  base  version.  We  can  merge  the  two  new  versions  A  and  C  by 
applying  the  change  that  produced  A  from  B  to  version  C,  or  by  applying  the  change  that 
produced  C  from  B  to  version  A.  The  result  is  the  same  in  either  case.  Earlier,  we  expressed 
the  (i  +  l)st  iteration  of  a  software  prototype  as  Si+1  =  5»  -f  ASj.  Let  us  consider  an  ith 
version  which  has  been  changed  in  two  different  ways,  via  Ax  and  A b-  The  results  of  these 
two  changes  are  denoted  as  Sa  and  Sb,  respectively.  Now  let  us  consider  a  case  where  the 
(i  +  l)st  iteration  is  the  result  of  merging  these  two  changes: 

5j+1  =  Sx[$i]5b  =  {Sa  “  Si)  U  {Sa  n  Sb)  U  {Sb  —  Si) 

The  components  of  $i+1;  Vf+i,  2?i+1  and  Q+1  can  be  computed  similarly: 

VS+i  =  Vx[Vi]VB  =  {Va  -  Vi)  U  (Vx  n  VB)  U  {VB  -  Vi) 

Ei+i  =  Ea[Ei]Eb  —  {Ea  —  Ei)  U  {Ea  H  Eb)  U  {Eb  —  Ei) 

ci+l  =  cA[Ci)cB  *  {Ca  -  Ci)  u  (CA  n  cB)  u  {cB  -  cfi 

To  demonstrate  the  concept  of  the  merging  operation,  we  provide  the  following 
example:  The  base  prototype  is  as  in  Figure  3.13.  Change  A  is  outlined  in  Figure  3.14,  with 
the  result  shown  in  Figure  3.15.  Change  B  is  outlined  in  Figures  3.16  and  3.17.  The  merging 
operation  is  performed  in  Figure  3.18  and  the  result  is  shown  in  Figure  3.19. 

The  merge  operation  outlined  in  Figure  3.18  involves  determining  the  real  effect  of 
changes  made  to  the  base,  and  any  conflict  that  may  arise  due  to  similar  changes  between  the 
two  variations.  This  is  a  simple  example  illustrating  the  merging  of  two  changed  prototypes 
which  do  not  conflict  with  one  another.  In  some  cases,  two  changes  to  a  prototype  can 
conflict  with  one  another,  and  the  result  of  their  merging  can  be  an  inconsistent  program. 
In  such  cases,  the  engineer  must  resolve  the  conflict  off-line. 
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Figure  3.13:  Fish  Farm  Control  System,  Fishies 
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AjiFishies  =  VAa,  VRA,  EAa,  ERa,  CAa,  CRa 

VAa  —  {Monitor  Saderia-Level,  Control-Water  Slowd,  Display  Statusd) 
VRa  =  {C  ontrol -W  aterJ'low ,  Display -Status} 

EAa  —  {(Bacteria-Status  :  M onitor Sacteria-Level  —*  Control-Water  JFlowJZ), 
(Bacteria  :  M  onitor  S  act  eria^ev  el  —*  Display  Siatusd) 

(02status  :  M  onitor -02itvel  — »  Control.WaterSlowd), 

(N  HZ  Status  :  M  onitor  JV HZ  -Lev  el  — ♦  Control-WaterSlowd ), 
(H20Status  :  Monitor -H20 -Level  —*  Control-WaterSlowd), 

(02  :  Monitor -02-Level  — ►  Display  Statusd), 

(NHZ  :  Monitor -NHZ -Level  — ►  Display  Status  d), 

(H20  :  M  onitor -H20 -Level  —*  Display  Status  J2), 

(Activated nlet :  Control.W aterSlowd  — ♦  Adjust  dnlet), 
(Activate-Drain  :  Control-WaterSlowd  — ►  Adjust -Drain), 

(InletS etting :  Adjust  Jnlet  — ♦  Display  Status d), 

(DrainSetting  :  Adjust-Drain  — »  Display  Status _2), 

(Feeding  :  Control  Seeder  — *  Display  Status  _2)} 

ERa  —  {(02Status  :  Monitor -02-Level  — ►  Control-Water-Flow), 

(NHZStatus  :  Monitor-N HZ  -Level  — ►  Control -Water-Flow), 
(H20Status  :  Monitor  JI 20 -Level  — ♦  Control-Water-Flow), 

(02  :  Monitor -02-Level  -*  Display  Status), 

(NHZ  :  M  onitor -N  HZ -Level  — ►  Display  Status), 

(H20  :  M  onitor  JI20 -Level  — ♦  Display  Status), 

(Activated nlet :  Control-Water-Flow  —*  Adjustdnlet), 
(Activate-Drain  :  Control-Water  Slow  — ♦  Adjust-Drain), 
(InletSetting :  Adjustdnlet  — ►  Display  Status), 

(DrainSetting  :  Adjust-Drain  — »  Display  Status), 

(Feeding  :  ControlSeeder  —*  Display  Status)} 

CAa  —  {max -txecJime(M  onitor Saderia-Levtl ,  100ms), 
max-exec-time(DisplayStatusJ2, 100ms), 
max-execjtime(ControLWaterSlowd, 200ms), 
period(Control-W aterSlowd,  2000ms)} 

C-R*  =  {max -txec-time(Display Status,  100ms), 

max -execJime(ControLWater  Slow,  200ms), 
period(Control-WaterSlow,  2000ms)} 


Figure  3.14:  Example  of  change  AA  applied  to  Fishies 
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Figure  3.1S:  Fishies^ 


AbFi  shies  = 

VAb 

VRb 

EAb 

ERb 

CAb 

CRb 


{VRb,  VAb ,  EAB ,  ERB,  CAB ,  C72b} 

{} 

{Get  -Feeding  JTime} 

{} 

{( Feed-Schedule  :  EXT  — »  Get -Feeding  J'ime), 
(Feed-Schedule  :  Get-Feeding -Time  — ♦  &XT)} 

{} 

0 


Figure  3.16:  Example  of  change  AB  applied  to  Fishies 


Figure  3.17:  Fishiest 


Fishiesu 

^Fiahiaatt  s 
F^Fiakiaau  ' 
C  FiaKiaau  '• 


-  FishiesA[Fishies]Fishiesg  = 

(FishiesA  —  Ft  shies)  \J(FishiesA  f|  F is  hies b)  \J(FishiesB  —  Fishies ) 

^mUm^  = 

iy^Fiahtaaji  Vpiahiaa)  LK^’wAiw,*  D  ^Fithiesg  )  U(^ri«Ate#^  Vpiahiea) 

F/FiakiaaA[E'Fiahita]FFisflieta  — 

{Fj Fiahiaaji  ~  ^fwkiu)  U(^FuMuj)  U(^F«iUm(  FpitKiea  ) 

@FiakiaaA  Fith*aa]C Ftakiaag  = 

{@F*ahiaaA  ^Fiahiea)  U(^FiahiaaA  D  ^Fiahiaag  )  U(^Fiahieag  Cpiahiea ) 


Figure  3.18:  Performing  the  Change-Merge  Operation 
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There  ere  e  somber  of  possible  conflicts  thet  can  arise  during  the  merging  operation. 
Conflicts  arise  when  different  changes  applied  to  the  prototype  affect  the  same  portion  of 
the  prototype  in  different  ways.  Some  examples  of  conflicts  are  as  follows: 

1.  One  change  adds  an  output  edge  to  a  vertex  A,  while  another  change  removes 
vertex  A  from  the  prototype.  In  this  case,  automatic  resolution  of  the  conflict  is  not  yet 
possible,  so  the  system  would  have  to  announce  that  a  conflict  has  occurred  and  give  the 
designer  the  opportunity  to  resolve  it.  In  the  case  of  such  a  conflict  the  construction  produces 
a  graph  that  is  not  well  formed,  in  the  sense  that  it  has  edges  whose  endpoints  do  not  belong 
to  the  vertex  set  of  the  graph  and  are  distinct  from  the  artificial  node  EXT  that  serves  as 
an  endpoint  for  external  flows. 

2.  The  two  changes  assign  different  timing  constraint  values  to  the  same  operator, 
i.e.,  ( max^exccJime,  F,  50ms )  and  (max-excc.timcy  F,40ms).  In  this  case,  the  conflict  can 
be  handled  automatically,  since  any  operator  that  executes  in  under  40ms  must  also  execute 
in  under  50ms.  In  situations  where  different  maximum  execution  times  have  been  assigned, 
the  minimum  value  can  always  be  chosen.  This  is  also  true  of  two  different  values  for  latency, 
maximum  response  time,  and  finish  within  timing  constraints.  The  minimum  calling  period 
timing  constraint  would  have  to  be  merged  using  the  maximum  of  the  different  values. 
Different  period  values  for  the  same  operator  in  different  changes  result  in  a  conflict  that 
would  have  to  be  resolved  by  the  designer.  Different  control  constraints  for  the  same  part  of 
the  prototype  in  different  changes  can  also  result  in  a  conflict.  Some  of  these  conflicts  can 
be  resolved  automatically. 

2.  Analysis 

The  approximate  method  described  above  provides  a  method  of  change-merging 
PSDL  implementations  that  is  closer  to  the  semantically  correct  version  than  the  first  at¬ 
tempt,  but  impossible  to  prove  correct.  The  next  two  chapters  detail  a  slicing  method  for 
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change-merging  which  is  easily  proven  correct.  Chapter  IV  details  a  semantic  model  of  PSDL, 
a  method  of  slicing  PSOL  programs,  and  a  change-merge  model  which  utilizes  these  slices  to 
create  a  merged  version  which  preserves  the  significant  changes  in  each  of  the  two  modified 
versions.  Chapter  V  details  the  algorithm  developed  to  implement  this  slicing  method  for 
change-merging.  This  new  slicing  method  has  been  implemented  and  integrated  into  the 
CAPS  development  system. 

G.  CONDITIONAL  MERGING  OF  WHILE-PROGRAMS 

One  of  the  main  weaknesses  of  traditional  approaches  to  data  flow  analysis  and  slicing  is 
insensitivity  to  the  conditions  under  which  data  flows  actually  take  effect.  This  problem  has 
prevented  conflict-free  merging  of  software  changes  that  affect  the  same  output  variable,  even 
in  cases  where  the  changes  affect  disjoint  portions  of  the  input  space.  One  way  to  improve  on 
this  is  to  augment  the  dependency  graphs  with  flow  guards,  so  that  disjoint  partial  flows  can 
be  distinguished,  and  successfully  merged.  A  software  merge  technique  based  on  conditional 
slices  captures  a  finer-grain  picture  of  the  threads  in  a  program  than  merging  based  on 
unconditional  slices,  and  hence  can  produce  more  accurate  program  merges. 


1.  Conditional  Flow  Dependencies 

There  is  a  flow  dependency  between  two  statements  in  a  while-program  if  a  value 
assigned  by  the  first  statement  can  be  read  by  the  second  statement.  Determining  flow 
dependencies  exactly  is  undeddable  in  the  general  case  [Ref.  13].  Conventional  data  flow 
analysis  calculates  a  weak  approximation  to  the  exact  flow  dependencies  by  assuming  that 
all  paths  in  the  control  flow  graph  of  a  program  are  feasible.  This  method  ignores  the 
possibility  of  infeasible  paths  and  non-terminating  loops  because  of  its  assumption  that  all 
control  predicates  are  satisfiable  along  all  possible  paths  through  the  control  flow  graph. 


45 


Conventional  flow  analysis  is  guaranteed  to  find  all  flow  dependencies,  but  it  may  report 
some  dependencies  that  are  not  really  there. 

In  [Ref.  13],  Berzins  introduces  conditional  flow  dependencies  to  provide  more  ac¬ 
curate  computable  approximations  to  exact  data  flow  dependencies.  A  conditional  flow 
dependency  is  a  conventional  flow  dependency  augmented  with  a  predicate  describing  the 
conditions  under  which  the  data  flow  can  take  place.  The  predicates  associated  with  the 
data  flows  enable  us  to  recognize  disjoint  flows  and  hence  provide  a  more  discriminating 
model  of  the  data  flow  dependencies  in  a  program. 

a.  Flow  Guards 

The  predicates  associated  with  each  conditional  flow  dependency  are  called 
flow  guards.  The  exact  flow  guard  associated  with  a  flow  dependency  carried  by  a  variable 
v  from  a  program  statement  si  to  another  program  statement  s2  is  true  in  a  program  state 
S  if  and  only  if  all  of  the  following  conditions  hold: 

1.  Statement  si  assigns  a  value  to  variable  v  when  executed  in  state  5. 

2.  Program  execution  will  subsequently  reach  the  statement  s2. 

3.  Statement  s2  will  read  the  value  assigned  by  statement  si  to  variable  v. 

An  approximate  flow  guard  must  be  true  whenever  the  exact  flow  guard  is 
true,  and  can  be  true  in  some  cases  where  the  exact  flow  guard  is  false.  The  set  of  all 
approximate  flow  guards  forms  a  lattice  with  respect  to  the  ordering  defined  by  the  logical 
implication  relation.  The  weakest  approximate  flow  guard  is  true  for  all  states,  and  the 
strongest  approximate  flow  guard  is  the  exact  flow  guard.  Conventional  data  flow  analysis 
is  equivalent  to  using  the  weakest  approximate  flow  guards. 

Checking  whether  exact  flow  guards  are  disjoint  is  undecidable  in  the  general 
case,  as  demonstrated  by  the  program  shown  in  Figure  3.20.  Statements  are  identified  by  the 
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line  numbers  shown  on  the  left  margin.  The  flow  guard  for  the  flow  of  x  from  statement  1  to 

* 

statement  4  is  disjoint  from  the  flow  guard  for  the  flow  of  y  from  statement  2  to  statement  4 
if  and  only  if  the  program  fragment  P  shown  on  line  3  terminates,  which  is  an  undecidable 
question.  Since  program  merging  algorithms  based  on  conditional  flow  dependencies  need  to 
check  whether  flow  guards  are  disjoint,  we  seek  representations  for  which  di  jointness  checks 
are  decidable. 


1  x  :=  1 

2  y  :=  2 

3  P 

4  z  :=  x  +  y 


Figure  3.20:  Undeddability  of  Disjointness  for  Guard  Conditions 

We  can  get  approximate  flow  guards  with  decidable  disjointness  relations  by 
using  a  logic  with  restricted  expressive  power  to  represent  the  flow  guards.  One  way  to  do 
this  is  to  use  propositional  guard  predicates. 

Propositional  guard  predicates  are  constructed  from  the  Boolean  constants  true 
and  false,  Boolean  condition  variables  associated  with  the  control  predicates,  the  Boolean 
connectives  &,  |,  and  ~,  and  the  modal  operators  of  the  form  (P),  where  P  is  the  condition 
variable  associated  with  the  control  predicate  of  a  while  loop  in  the  program. 

Propositional  guard  predicates  are  interpreted  as  follows.  Condition  variables 
represent  the  value  produced  by  the  most  recent  evaluation  of  the  associated  control  predi¬ 
cate.  The  connectives  &,  |,  and  ~  represent  the  “and”,  “or”  and  “not”  operators  of  standard 
propositional  logic. 
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P  m  (V*)  *b®§m*  (V*)  “is"  S  “end*  ( V*) 
SmV:*E 


I  S;S 

j  “if"  E  “then"  S  “else”  5  “fi” 
|  “while”  E  “do”  5  “od" 


Figure  3.21:  While  Program  Grammar 
b.  Conditional  Dependency  Graph* 

Conditional  flow  dependencies  are  represented  by  a  conditional  program  de¬ 
pendency  graph.  A  conditional  program  dependency  graph  consists  of  a  set  of  vertices  and 
a  set  of  edges.  The  set  of  vertices  contains  a  vertex  for  each  assignment  statement,  an 
initiaLstate  vertex,  and  a  final  vertex  for  each  output  variable.  The  set  of  edges  repre¬ 
sent  conditional  flow  dependencies  and  control  dependencies.  Control  dependency  edges  are 
needed  to  provide  a  flow  path  between  two  sequential  parts  of  a  program  which  do  not  share 
any  variables.  Control  dependency  edges  are  identical  to  flow  dependency  edges  that  do  not 
carry  a  variable. 

We  illustrate  the  construction  of  a  conditional  flow  graph  in  terms  of  a  simple 
imperative  programming  language  that  provides  assignments  to  scalar  variables,  sequencing, 
conditionals,  and  while  loops.  This  language  of  while-programs  does  not  have  any  explicit 
input  or  output  statements,  and  is  defined  by  the  grammar  shown  in  Figure  3.21. 

The  nonterminals  P,  5,  E,  and  V  represent  while-programs,  statements,  ex¬ 
pressions,  and  variables,  respectively.  The  Kleene  star  (*)  denotes  zero  or  more  instances  of 
the  preceding  symbol. 

The  input  variables  of  a  while-program  are  listed  before  the  “begin”,  and  the 
output  variables  are  listed  after  the  “end”.  All  other  program  variables  are  listed  between 
the  keywords  “begin”  and  “is”.  The  meaning  of  a  program  is  characterized  by  the  final  values 
of  its  output  variables.  The  meaning  of  a  program  statement  is  characterized  by  its  effect 
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on  the  program  state.  The  program  state  consists  of  the  values  bound  to  all  of  the  program 

% 

variables.  The  meaning  of  an  expression  is  characterized  by  the  value  of  the  expression  in 
the  current  program  state.  The  evaluation  of  an  expression  cannot  affect  the  program  state. 

An  attribute  grammar  is  provided  in  [Ref.  13]  for  constructing  the  conditional 
flow  graph  for  a  while-program.  The  nodes  of  the  flow  graph  correspond  to  the  assignment 
statements  in  the  program,  along  with  an  extra  initial  vertex  and  a  final  vertex  for  each 
output  variable.  Each  node  is  associated  with  an  execution  guard.  The  execution  guard  is  a 
predicate  that  represents  the  set  of  program  states  in  which  the  statement  can  be  executed. 
Each  edge  of  the  flow  graph  is  associated  with  a  variable  name  and  a  flow  guard.  The 
variable  name  identifies  the  data  carried  by  the  edge.  The  flow  guard  is  a  predicate  that 
represents  the  set  of  program  states  in  which  the  value  of  the  variable  flows  along  the  edge. 
The  flow  guard  is  the  conjunction  of  the  conditions  that  the  source  node  is  executed,  that 
the  destination  node  is  executed,  and  that  all  loops  on  the  control  path  from  the  source 
node  to  the  destination  node  terminate.  Since  each  node  can  define  the  value  of  at  most  one 
variable,  there  can  be  at  most  one  edge  between  any  pair  of  nodes  in  the  flow  graph.  An 
example  of  a  Conditional  Flow  Graph  is  shown  in  Figure  3.22. 


Figure  3.22:  An  Example  of  a  Conditional  Dependency  Graph 
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2.  Conditional  Slices 


A  slice  of  a  program  isolates  that  portion  of  the  code  which  affects  the  program 
behavior  with  respect  to  some  program  statement.  A  conditional  slice  must  differentiate 
between  portions  of  the  code  that  affect  the  meaning  of  that  program  statement,  but  under 
different  conditions.  We  define  a  conditional  slice  of  a  while-program,  with  respect  to  a 
program  statement  and  a  flow  guard,  on  the  program’s  conditional  dependence  graph,  G. 

For  program  statement,  5  and  flow  guard,  P,  the  slice  of  G  with  respect  to  5  and 
P,  G/{S,  P]  is  a  subgraph  of  G  and  contains  all  vertices  Vi  €  G,  such  that  there  is  a  path 
from  v,  to  5  along  control  dependence  edges  or  flow  dependence  edges  not  labeled  with  the 
flow  guard  ~  P.  The  edges  in  the  slice  are  all  of  the  edges  that  connect  the  vertices  in  the 
slice.  An  example  of  a  conditional  slice  is  shown  in  Figure  3.23. 


SUcey^,)(HnaKv).  P) 

begin 

y:»0; 

P  if  x>0 
then 

Q  while  x  >  0  do 

y:*y  +  x; 
x^x- 1; 
od 
end  if; 
end(y): 


Figure  3.23:  Slice  Base/  {Final(y),  P} 
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A  conditional  slice  of  a  program  is  itself  a  program,  as  it  contains  all  of  the  orig- 

.9 

inal  program  code  which  affects  the  values  computed  at  the  final  vertex  when  the  input  is 
restricted  .o  only  those  inputs  which  satisfy  the  given  conditions. 

3.  Conditional  Program  Merging 

Other  approaches  to  merging  while-programs  use  pieces  of  each  of  the  input  versions 
to  perform  the  merge[Ref.  28, 48].  One  of  these  program  pieces  is  the  part  of  the  two  modified 
versions  which  is  the  same.  This  part  is  known  as  the  preserved  part  The  remainder  of  the 
merged  program  comes  from  that  part  of  each  of  the  modified  versions  which  is  different 
from  the  base.  These  parts  are  called  the  affected  parts  of  each  modification.  Construction 
of  these  program  pieces  is  done  using  program  slicing. 

The  preserved  part  is  constructed  by  comparing  slices  of  each  of  the  modified 
versions  with  respect  to  subsets  of  the  program  statements.  The  largest  subset  of  program 
statements  that  has  the  same  slice  in  all  three  versions  defines  the  preserved  part.  The 
affected  part  of  each  of  the  modified  versions  is  constructed  by  comparing  the  slice  of  the 
modification  with  respect  to  each  of  its  vertices  against  the  same  slice  of  the  base  version. 
If  the  slices  are  different  in  the  modification  and  the  base,  then  that  slice  is  in  the  affected 
part. 

One  of  the  problems  inherent  in  this  method  of  program  merging  is  its  inability  to 
distinguish  between  different  changes  to  the  same  slice  which  cannot  interfere.  Conditional 
slicing  alleviates  this  problem  by  allowing  the  different  computation  paths  which  can  never 
be  executed  for  the  same  input  to  be  considered  separately. 

Using  conditional  slicing,  we  calculate  the  affected  part  of  a  modified  version  by 
comparing  slices  of  the  modified  version  with  respect  to  the  program  statements  and  the  set 
of  all  possible  truth  values  of  the  conditional  guard  predicates  at  that  statement.  In  this 
way,  two  different  paths  to  the  same  statement  which  cannot  be  taken  on  a  single  input  are 
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not  contained  in  the  same  slice,  thus  changes  to  one  path  do  not  necessarily  affect  the  slice 
containing  the  other  path. 


The  merged  program  is  then  constructed  in  the  same  way  as  the  unconditional 
method,  by  taking  the  graph  union  of  the  preserved  part  and  the  affected  parts  of  both 
modifications. 

Consider  the  example  outlined  in  Figures  3.24  through  3.29.  In  this  example,  the 
base  version  is  the  same  as  that  shown  in  Figure  3.22  and  contains  a  conditional  expression 
that  partitions  the  input  space  into  positive  and  negative  integers.  If  the  input  value  of  x 
is  negative,  then  one  set  of  statements  is  executed  and  if  it  is  positive,  then  another  set  of 
statements  is  executed.  In  Figure  3.24,  you  see  a  change  made  to  the  then  branch  of  the 
conditional  expression.  In  Figure  3.25,  you  see  a  change  to  the  else  branch  of  the  conditional. 
Since  both  of  these  branches  affect  the  same  output  variable,  y,  the  traditional  approach  to 
merging  would  report  a  conflict  and  the  merge  would  fail.  This  should  not  be  the  case, 
however,  since  these  two  changes  can  never  interfere. 
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B(x) 

begin 
y :»  0; 

P  if  x>0 

then 

Q  while  x  >  0  do 

yr»y  +  x; 
x :»  x  - 1; 
od 
else 

^  while  x<  0  do 

y:*y/x; 
x»x+  1: 
od 
end  if; 
end(y); 


Figure  3.25:  Version  B 


Figure  3.26:  Preserved  Part  of  ail  Three  Versions 
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P 

Q 


R 


begin 

y*0: 

ifx>0 

then 

whilex>Odo 
y*ymx 
x  :«x- 1; 

od 

else 

while  x<  0  do 
y^ylr. 
x:*x+  l; 


od 
end  if; 
endOO; 


Figure  3.29:  Merged  Version 
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IV.  SEMANTIC  MODEL 


In  this  chapter  we  describe  our  model  for  the  behavior  of  prototypes,  present  our  slicing 
method  for  change-merging  prototypes,  and  present  an  invariance  theorem  that  guarantees 
our  method  is  correct. 

A.  PROTOTYPING  SYSTEM  DESCRIPTION  LANGUAGE 

The  Prototyping  System  Description  Language  (PSDL)  is  an  enhanced  data  flow  lan¬ 
guage  that  can  be  used  to  specify  and  implement  prototypes  of  real-time  embedded  software. 
PSDL  programs  are  inherently  non-deterministic  and  can  be  executed  in  parallel  [Ref.  32]. 
This  section  describes  a  semantic  execution  model  for  PSDL  programs. 

1.  Overview  of  PSDL  Semantics 

Our  change-merging  method  is  based  on  the  behavior  of  the  input  programs  and  not 
on  their  syntax.  In  this  section  we  define  a  behavior  model  for  PSDL  that  we  can  use  to  prove 
our  invariance  theorem.  The  semantics  of  PSDL  have  been  modeled  using  algebraic  high-level 
Petri  nets  [Ref.  32].  We  chose  a  different  model  which  is  more  applicable  to  our  problem.  We 
chose  to  model  the  behavior  of  a  prototype  by  observing  the  data  flow  history  over  its  data 
streams.  A  prototype’s  behavior  is  represented  by  sets  of  possible  histories  over  the  streams 
we  call  traceJtaplts.  These  trace-tuples  are  composed  of  sequences  of  data-tuples  called 
tracts.  Each  trace -tuple  contains  precisely  one  trace  per  stream.  Since  PSDL  prototypes  are 
non-deterministic,  one  trace-tuple  does  not  necessarily  reflect  the  set  of  possible  histories 
associated  with  a  prototype,  thus  we  must  consider  the  behavior  of  a  prototype  to  be  the 
set  of  all  possible  trace-tuples  over  its  data  streams.  Since  PSDL  prototypes  are  intended 
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to  prototypo  embedded  real-time  systems,  which  may  never  be  turned  off,  this  behavior  is 
likely  to  be  of  infinite  length.  We  use  tracejtuples  as  the  base  unit  for  our  inductive  proof  of 
the  invariance  theorem  in  Section  B.2  of  this  chapter.  The  following  subsections  describe  the 
model  starting  with  traces  and  building  up  to  the  behavior  of  a  prototype,  and  the  possibility 
functions  we  use  to  construct  the  behaviors. 

2.  Traces 

The  history  of  a  PSDL  computation  can  be  described  by  the  histories  of  all  the 
data  streams,  called  traces.  A  tract  on  a  data  stream  z,  denoted  rz,  is  the  sequence  of  all 
data  tuples  on  the  stream.  Each  data  tuple  contains  a  data  element  zj,  the  name  oj  of  the 
operator  responsible  for  writing  zj  to  the  stream,  the  time  tw\  that  x\  was  written  to  the 
stream,  and  the  time  trj  at  which  oj  read  its  input  streams  to  start  the  computation  that 
produced  zj.  A  data  tuple  represents  the  assertion  that  the  value  zj  was  produced  by  an 
execution  of  o|  that  started  at  time  irj  and  finished  at  time  tw\. 

Example  1  Ihtcc  on  a  ftmm  z 

Tx  -  [[*o,  Go,  *r0, <u>o],  (zlf  p|,  tru  tu^], ...,  [*i,  oj,  twl\,  •••] 

Since  PSDL  was  designed  far  writing  prototypes  of  real-time  embedded  software 
systems  that  may  never  be  turned  off  once  started,  traces  can  be  finite  or  countably  infinite. 
The  initial  data  tuple  on  a  data  stream  is  (z0  — *  -L,  oo  -*  JL,  two  —♦  0,  tr0  — ♦  0],  where 
JL  represents  an  undefined  value,  unless  the  stream  is  declared  as  a  state  variable  with  an 
initial  value,  in  which  case  the  initial  data  tuple  would  be  [z0  — »  v,  oo  —>  DECL.OP,  tw0  —* 
0 ,tr0  — ►  0].  DECL.OP  is  the  operator  in  which  the  state  declaration  appears,  and  r  is  the 
initial  value  assigned  in  that  declaration.  For  example,  if  the  state  stream  is  declared  in  an 
operator  p  by  the  declaration  statement  STATE  z  INITIALLY  3,  then  the  initial  data 
tuple  on  the  stream  would  be  [3,  P,  0,  0].  Since  every  trace  contains  an  initial  data  tuple, 
we  see  that  all  traces  are  non-empty  and  that  the  minimum  length  of  a  trace  is  one.  In  a 
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data  Bow  dream,  when  a  data  element  i*  removed  from  the  stream  and  there  is  not  another 
dement  on  the  stream,  the  value  and  the  operator  name  elements  are  replaced  by  X. 

The  write  times  tw j  for  a  given  stream  form  a  monotonically  increasing  sequence 
of  numbers  that  represent  the  amount  of  time  elapsed  between  when  the  prototype  began 
execution  and  when  the  value  was  available  on  the  stream.  The  read  times  tr\  for  a  given 
stream  form  a  monotonically  increasing  sequence  of  numbers;  the  ith  element  in  the  sequence 
represents  the  amount  of  time  elapsed  between  when  the  prototype  began  execution  and  when 
the  operator  oj  read  its  input  streams  at  the  start  of  the  computation  responsible  for  xj. 

If  an  operator  fails  to  terminate  on  any  firing,  then  the  trace  on  any  of  its  output 
streams  contains  only  the  values  which  were  written  to  the  stream  before  the  firing  in  which 
the  operator  failed  to  terminate.  If  the  failure  to  terminate  occurs  during  the  first  firing  and 
no  other  operator  can  write  to  the  stream,  the  trace  contains  only  the  data  tuple  representing 
the  initial  value. 

A  trace,  tx  can  also  be  represented  by  a  stream  function  from  a  write  time  to  a 
triple  containing  the  value,  the  id  of  the  operator  which  wrote  the  value  and  the  read  time: 
V  :  TIME  — ♦  TYPE(x)  x  OPJD  x  TIME ,  where  TYPE{x)  denotes  the  set  of  all 
possible  values  that  can  be  written  to  the  stream  x,  OPjD  is  the  set  of  all  possible  operators 
that  can  write  to  the  stream,  and  TIME  is  a  non-negative  real  number.  We  chose  time  to 
be  a  continuous  value  since  prototypes  can  be  executed  in  parallel,  and  we  cannot  guarantee 
that  different  processors  will  execute  a  precisely  the  same  speeds. 

Example  2  Stream  Function  Representation  for  a  Trace 

A  trace  for  a  stream  x  is: 

T,  =  ([X,  X,  0, 0],  [xj,  o,  2, 3],  [xi#p,  6, 7]] 
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The  stream  function  representation  for  this  trace  would  be: 


I  [0,3)  — .  [X.X.O) 

*.-{  [3,7)  —  [*i,o,2) 

l  (7,oo)  — >  [*„p,6j 

III  order  to  use  these  different  representations  interchangeably,  we  need  to  show 
that  they  are  equivalent.  Consider  the  function,  ♦,  shown  in  Figure  4.1.  ♦  is  a  bijection 
that  maps  a  sequence  of  data  tuples  into  a  step  function,  9,  which  is  continuous  only  from 
the  right. 

¥(<)*  hm,Vt 

Limits  from  the  left  are  not  preserved  at  the  boundaries  between  the  data  tuples,  however. 

Theorem  2  9  is  well-defined  and  a  bijection  when  restricted  to  right  continuous  step  func¬ 
tions  with  countable  range  sets. 

Proof:  See  Appendix  C. 


*(r.)  =  where  ♦.(<)  =  [xn,On,trn] 

where  [zn,Pn,tu>li,ir1|]  €  r„  n  €  N  &  fafe  <  t  k  (n  =  length (rx)  or  ii^n+i  >  t) 

#“1(4r«)  =  r,  where  [xj,o,  fu>i,*ri]  €  r*  iff 

(  =  [*l»  o,  <n]  &  tvn  =  min«(¥«(<)  =  [xj,  o,  trj])  ) 


Figure  4.1:  ♦  :  Traces  — ►  FunctionRcprcsentations 

The  meaning  of  an  operator  is  characterized  by  &  relation  between  the  traces  on 
the  input  streams  and  the  traces  on  the  output  streams.  If  a  data  stream  receives  input  from 
more  than  one  producer,  then  we  must  have  a  method  for  merging  multiple  traces  into  one 
to  determine  the  behavior  of  the  entire  system.  The  merge  function,  defined  in  Appendix 
A,  Section  3,  provides  this  method  for  two  traces,  A  and  B.  It  can  easily  be  generalized  to 
any  finite  number  of  traces. 


59 


A  etream  behavior  Ux  a  stream  x,  0m,  is  the  set  of  all  possible  traces  for  x.  Since  a 
PSDL  computation  can  be  non-deterministic,  the  history  of  a  computation  is  represented  by 
the  set  of  all  possible  traces  for  a  given  PSDL  stream.  Since  the  complete  stream  behavior 
for  a  data  stream  in  a  PSDL  prototype  may  not  be  visible  from  outside  the  prototype,  it 
is  necessary  for  us  to  consider  both  visible  and  generated  stream  behaviors  for  a  stream.  A 
visible  stream  behavior  ior  a  stream  x  is  a  set  of  traces  written  to  x  by  an  external  producer. 
Each  trace  in  the  visible  stream  behavior  of  x  is  a  subsequence  of  some  trace  in  the  complete 
stream  behavior  for  x.  The  part  of  the  stream  behavior  which  is  not  produced  externally, 
we  call  the  generated  stream  behavior.  The  traces  in  the  generated  stream  behavior  for  x 
are  also  subsequences  of  traces  in  the  complete  stream  behavior  for  x.  For  example,  consider 
either  of  the  prototypes  in  Figure  4.2.  Each  trace  in  the  stream  behavior  of  x,  is  a  sequence 
which  contains  as  subsequences  the  traces  on  the  hidden  and  visible  parts  of  x.  Thus  the 
visible  behavior  and  the  generated  behavior  are  both  projections  of  the  complete  stream 
behavior. 


A  truncated  trace  for  a  stream  x,  rx  |  fc,  is  a  finite  prefix  of  tx  for  which  length(rx  \ 
k  =  min(length(rx),  k)  A  truncated  stream  behavior  for  a  stream  x,  fix  |  k  is  the  set  of  all 
possible  truncated  traces,  rx  \  k. 

3.  Trace  Tuples  and  Prototype  Behaviors 

A  truce  tuple  is  a  tuple  containing  a  trace  for  each  stream  in  a  prototype.  A  trace 
tuple  can  be  projected  downward  to  any  subset  of  the  streams  in  a  prototype,  say  AT,  by 
including  in  the  projected  trace  tuple  only  those  traces  on  the  streams  in  X.  A  trace  tuple, 
T,  projected  downward  to  a  subset  X  of  the  streams  of  the  prototype  is  represented  as  Tx- 
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HB  -  Hidden  Behavior 
GB  -Given  Behavior 
SB  -Stream  Behavior 


Figure  4.2:  Example  of  prototypes  with  generated  stream  behaviors. 


As  samrapie  of  a  trace  tuple  over  the  eet  of  date  streams  in  a  prototype  E{P)  is 
(r«iiT«t'"'irn)'  *1  €  E(P).  A  visible  trace  tuple  is  a  tuple  of  visible  traces  for  each  stream 
in  the  prototype.  A  truncated  trace  tuple  is  a  trace  tuple  containing  only  truncated  traces: 

(T*| >  ••*,  ‘Jrj)  I  ^  =  ((**|  I  I  ^)) 

A  trace  tuple  can  also  be  viewed  as  a  vector-valued  stream  function  by  extending 
the  function  ♦  to  trace  tuples  according  to  the  rule: 

+((T.i,...,T,J))(l)  =  <*(T,1)(t) . *(r,J)(<)>  =  *(‘) 

9(t)  is  a  vector  containing  one  data  tuple  from  each  trace  in  the  trace  tuple,  the  value 
present  on  each  stream  at  time  t.  Using  ♦,  we  can  also  view  a  trace  tuple  as  a  sequence  of 
vectors,  where  each  vector  contains  the  data  tuple  present  on  each  stream  at  a  write  time  t 
for  one  of  the  streams  in  the  tuple. 

Example  S  Example  of  a  Trace  Tuple  on  two  streams. 


For  a  set  of  streams  X  =  {x,y}  with  [[X,X,0,0],[xi,o,2,3],[x2,p,6,7]]  and 
rv  =  [[-L,  X,  0, 0],  [yj ,  o,  3, 5],  [ya,  o,  7, 9]],  the  resulting  trace  tuple  is: 

(H-h,  X,0, 0],  [x\,o,  2,3],  (*2  ,p,  6, 7]],  [[X,  X,  0, 0],  [yi,  o,  3, 5],  [y*,  o,  7,9]]) 

and  the  corresponding  function  representation  is: 

(0,3)  — ►  <[X,X,0],[X,X,0]) 

[3,5)  —  ([zi,o,2],  [X,X,0]) 

[5,7)  — ►  ([*i,o,2],[yi,o,3]) 

[7,9)  — ►  {[*2,F,6],[yi,o,3]) 

(9,oo)  — ►  ([*3,P,6],[ya,o,7]) 


Since  PSDL  is  non-deterministic,  there  may  be  many  possible  trace  tuples  for  a 
prototype  P.  We  call  the  set  of  all  possible  trace  tuples  for  the  data  streams  in  P,  the 
prototype  behavior  of  P,  and  we  represent  it  as  B. 


A  prototype  behavior  can  also  be  projected  downward  to  any  subset  of  the  streams 
in  a  prototype,  say  X ,  by  including  in  the  projected  data  flow  history  only  the  possible 
projected  trace  tuples  over  X.  A  projected  data  flow  history  over  a  set  of  streams  X  is 
represented  as  B*.  An  input  prototype  behavior  for  a  prototype  P  is  the  set  of  all  possible 
visible  trace  tuples  over  the  streams  in  P. 

Example  4  Example  of  a  projected  prototype  behavior  on  a  set  containing  two  streams. 

Consider  the  following  set  X  =  {x,  y},  where  the  stream  behavior  for  x  is  a  single 
trace,  [[X,X,0,0],  [xi,o,2,3],[x2,p,6,7]]  and  the  stream  behavior  for  y  contains  two  dif¬ 
ferent  traces,  {[[X, X, 0, 0],  [yi, o, 3, 5],  [y2,  o,  7, 9]],  [[-L,  X, 0, 0],  [y, , o , 4, 6),  (y2,  o, 6, 8)]}.  Then 
the  resulting  prototype  behavior,  Bjr  is: 


{([[X,  X,  0, 0],  [xi ,  o,  2, 3],  [x2,p,  6, 7]],  [[X,  X,  0, 0],  [y„  o,  3, 5],  [y2,  o,  7, 9]]), 


([(-^->  ®]>  [*ii  o,  2, 3],  [x2,p,  6, 7]],  [[X,  X,  0, 0],  [yi,  o,  4, 6],  [y2,  o,  6, 8]]) } 


The  function  representation  corresponding  to  B*  is: 

{  [0,3)  — >  <[X,X,0],[X,X,0]) 

[3,5)  —  {[x1,o,2],[X,X,0]> 

[5,7)  — »  ([*1,0,2],  [yi, o,3]) 

[7,9)  — ►  ([*3,P,6],[yi,o,3]) 

[9,  oo)  — ►  ([*a,P,6],[y2,o,7]), 


[0,3)  <[X,X,0],[X,X,0]) 

[3.5)  —  ([xi,o,2],[X,X,0]) 

[5.6)  — ►  ([*i,o,2],  [yi,  o,4]) 

[6, 8)  — ►  ([*2,  p,  6],  [yi,o,  4]) 

[8,  oo)  — ►  ([*2,P,6],[y2,o,6j)  } 

A  truncated  prototype  behavior,  B  |  lb  is  the  set  of  all  possible  truncated  trace  tuples,  up  to 
length  k. 


To  prove  our  slice  behavior  invariance  theorem,  we  also  need  to  extend  truncated 
trace  tuples  of  length  k  to  length  k  +  1  by  adding  one  data  tuple  onto  selected  traces  in 
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the  trace  tuple.  We  define  an  incremental  trace  tuple  to  be  a  vector  of  sequences  of  data 
tuples  over  a  set  of  streams,  where  the  length  of  each  sequence  is  either  zero  or  one,  and  the 
write  times  for  all  of  the  data  tuples  are  the  same.  An  incremental  trace  tuple  represents  the 
output  caused  by  one  firing  of  a  set  of  zero  or  more  operators  writing  to  different  streams  of 
the  prototype.  We  need  a  function  0  for  appending  sets  of  possible  incremental  trace  tuples 
on  to  the  end  of  a  truncated  trace  tuple.  The  0  function  is  defined  in  Appendix  A.  This 
function  takes  as  operands,  a  truncated  trace  tuple  over  the  streams  in  a  prototype  and  a 
set  of  possible  incremental  trace  tuples  over  the  streams  in  the  prototype,  and  it  produces 
the  set  of  all  possible  trace  tuples  resulting  from  adding  each  of  the  incremental  trace  tuples 
onto  the  end  of  the  corresponding  sequence  in  the  original  trace  tuple,  for  each  data  stream. 
Figure  4.3  shows  a  summary  of  the  constructs  defined  in  the  semantic  model  of  PSDL. 


time  = 

dataJuple{t :  type}  = 

trace  = 

stream  .behavior  = 

traceJuple  — 

incremental  Jracejtuple  = 
prototype  .behavior  = 


{*  €  8  |  *  >  0} 

tuple{x  :tyo:  opJd ,  tr,  tw  :  time} 
sequence{dataJuple } 
set{trace } 

tuple{streami :  trace } 
vector{t :  trace}  ::  length{t)  <  1 
set{traceJvple} 


Figure  4.3:  Summary  of  Model  Constructs 

4.  Possibility  Functions 

Each  operator  in  a  PSDL  prototype  has  an  input  history  and  an  output  history. 
The  input  history  of  an  operator  o  is  defined  as  the  prototype's  behavior  projected  over  the 
input  streams  of  o,  B/(0),  and  the  output  history  of  o  is  the  set  of  all  possible  trace  tuples 
written  by  o  to  its  output  streams. 

In  a  PSDL  prototype,  when  an  operator  fires,  it  reads  one  data  value  from  each  of 
its  input  streams  and  writes  at  most  one  output  value  to  each  of  its  output  streams.  The  data 
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value*  written  and  the  streams  they  are  written  to  are  determined  by  the  semantic  meaning 
of  the  PSDL  operator  and  the  associated  control  constraints.  Since  PSDL  operators  are 
non-determi rustic,  their  meanings  are  possibility  functions.  For  every  possible  input,  there 
is  a  set  of  possible  outputs. 

To  define  the  possibility  function  for  an  operator  o,  we  look  at  a  trace  tuple  pro¬ 
jection  of  the  behavior  a  6  B/(a)  as  a  sequence  of  input  vectors  to  o.  For  every  finite  prefix 
of  a  applied  to  o,  the  result  is  a  set  of  possible  incremental  trace  tuples  over  the  output 
streams  of  o.  This  is  the  possibility  function  for  o,  Ta  :  B/(»)  — *•  B o(o)-  ?o  takes  as  input 
a  projected  trace  tuple  over  the  input  streams  of  o  and  a  read  time,  and  produces  a  set  of 
possible  behavior  projections  over  the  output  streams  of  o.  The  read  time  is  the  time  at 
which  the  last  read  operation  was  performed  by  o  on  its  input  streams,  and  defines  which 
values  were  read  by  o  to  perform  this  computation. 


Example  5  Possibility  function  for  an  operator  p  which  implements  the  function: 


ft  = 


7,  =  {({3},9),({3,-4}.16),({3,-4,9},81) . ({3, -4,9 . I*},**’),...} 


Example  6  Possibility  function  for  an  operator  q  which  implements  the  state  machine: 

k 

iml 

7,  =  {({3}, 3),  ({3,  -4},  -1),  ({3,  -4, 9},  8) . ({3,  -4, 9 . **},  (£  x.)  i-x^,..} 

\  i*l  / 


In  example  5  you  will  notice  that  the  y  value  of  each  pair  is  dependent  only  on  the 
most  current  value  written  to  the  input  stream  z.  In  example  6  the  y  value  of  each  pair  is 
dependent  not  only  on  the  most  current  value  written  to  the  input  stream  z,  but  also  on  the 
previous  value  of  y. 
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The  effects  of  all  PSDL  control  constraints  can  be  expressed  as  transformations 

.# 

on  the  possibility  function  of  a  bare  primitive  operator.  The  effect  of  each  type  of  control 
constraint  on  a  possibility  function  is  defined  explicitly  in  Appendix  B.  In  the  rest  of  this 
chapter,  we  assume  that  the  possibility  function  for  each  operator  includes  the  effects  of  any 
associated  control  constraints. 

To  analyze  the  effects  of  various  approaches  to  change  merging,  we  assume  that 
the  possibility  function  for  a  network  of  PSDL  operators  can  be  derived  from  the  possibility 
functions  for  the  individual  operators  in  the  network.  This  can  be  done  as  follows. 

We  consider  a  prototype  P  to  be  a  network  of  operators  connected  by  the  data 
streams  of  P,  with  behavior  B.  B  is  the  behavior  of  the  entire  prototype.  Each  operator 
contributes  to  this  behavior  by  reading  from  its  input  streams  and  writing  to  its  output 
streams.  The  values  written  are  determined  by  the  possibility  function  of  the  operator.  We 
can  derive  the  possibility  function  for  the  prototype  P  from  the  possibility  functions  of  the 
individual  operators  using  the  following  construction: 

*>=U  U  (©[  U  (u 

T€ B  Ls€*(V(P))  \o€S  \tr<# 

This  construction  produces  a  set  of  incrementaLtrace-tuples  over  all  of  the  streams 
in  P.  The  possibility  function  for  each  individual  operator  J~0  is  at  the  heart  of  this  con¬ 
struction.  It  produces  a  set  of  incrementaLtrace-tuples  over  its  output  streams.  This  incre- 
mentaLtrace-tuple  is  extended  to  cover  all  of  the  streams  in  the  prototype  by  the  function 
fill.  The  function  A  is  then  used  to  isolate  each  incrementaL trace. tuple  attributable  to  a 
particular  read  time  tr  and  these  are  combined  over  all  possible  read  times  up  to  the  current 
time  t.  These  incrementaLtrace-tuples  are  then  combined  using  the  function  p  to  pick  out 
the  latest  possible  write  time  or  read  time  depending  on  whether  the  operator  contains  a 
feedback  loop.  Each  of  these  sets  of  incrementaLtrace-tuples  for  individual  operators  are 
then  combined  with  sets  produced  by  other  operators  in  the  subset  5  using  the  function  0. 
This  is  done  for  every  possible  subset  5  in  the  powerset  of  the  vertices  of  P.  Finally,  these 
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sets  of  incrementaLtrace-tuples  are  combined  for  every  possible  trace-tuple  in  the  behavior 
B  of  P. 

To  construct  the  truncated  behavior  of  P  of  size  k ,  we  have  to  not  only  produce 
the  set  of  incrementaLtrace-tuples,  we  have  to  append  them  to  the  set  of  truncated  trace 
tuples  of  size  k  —  1.  That  can  be  done  as  follows: 

B|*=  U  U  r®(©(  u  (u A(t,fiii{E(P),r.(TI(.t,tr 

T€B|(*-1)  Ls€T’{V(P))  \oeS  V(l\o)<tr  W< 

This  construction  is  identical  to  the  previous  construction  up  to  the  point  where  the  combina¬ 
tion  over  subsets  occurs.  At  this  point,  we  must  append  the  set  of  incrementaLtrace-tuples 
produced  by  the  0  function  for  each  subset  of  the  operators  to  the  trace.tuple  T  in  the 
truncated  behavior  B  |  (k  —  1).  This  guarantees  us  that  we  have  considered  every  possible 
combination  of  operators  firing  at  precisely  the  same  time.  The  result  of  this  construction 
is  then  a  set  of  possible  trace  tuples  truncated  at  length  k.  This  construction  assumes  that 
the  truncated  B  of  size  A:  —  1  is  known.  Precise  definitions  for  the  functions  0,  A,  p  and  fill 
can  be  found  in  Appendix  A. 

In  our  work,  we  assume  that  execution  of  the  prototype  is  “fair",  in  the  sense 
that,  any  operator  which  terminates  in  isolation  will  terminate  when  executed  as  part  of 
a  prototype.  Failure  of  an  operator  to  terminate  is  represented  by  a  possibility  function 
that  gives  the  same  set  of  possible  output  sequences  for  all  possible  extensions  of  an  input 
sequence  that  fails  to  terminate. 

B.  SLICING  OF  PSDL  PROTOTYPES 

As  we  saw  in  Chapter  III,  Section  C.2,  a  portion  of  a  program’s  behavior  can  be 
captured  by  a  slice  of  the  program  with  respect  to  a  single  point  in  the  program.  We 
have  developed  a  similar  method  that  is  also  valid  for  isolating  a  portion  of  the  behavior  of 
a  prototype.  This  section  describes  our  method  for  taking  slices  of  PSDL  prototypes.  One 
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of  the  differences  between  dicing  for  PSDL  prototypes  and  slicing  for  while  programs  is  that 
PSDL  programs  are  inherently  concurrent  and  non-deterministic.  While  programs  represent 
individual  deterministic  sequential  processes.  This  represents  a  major  contribution  of  this 
work. 


1.  Prototype  Dependence  Graphs 


Since  PSDL  implementations  are  graphs,  we  do  not  need  a  deep  transformation  to 
translate  our  prototypes  into  graphs  as  is  the  case  for  while  programs.  The  only  information 
we  need  to  add  to  the  current  PSDL  implementation  graph  are  dependencies  resulting  from 
timer  interactions,  and  an  external  vertex.  The  external  vertex  is  added  to  allow  slices  of 
prototypes  with  vertices  that  have  no  outputs  to  include  those  vertices.  The  following  defines 
our  Prototype  Dependence  Graph  (PDG): 

Definition  4  PSDL  Prototype  Dependence  Graph; 

A  Prototype  Dependence  Graph  (PDG)  for  a  prototype  P  is  a  fully  expanded  1 
PSDL  implementation  graph  G p.  In  the  PDG,  Gj>  =  (V,  E,C),  the  set  of  vertices  has  been 
augmented  with  an  external  vertex,  EXT,  and  the  set  of  edges,  E,  has  been  augmented  with 
a  timer  dependency  edge  from  oj  to  oj,  for  each  pair  of  vertices  oj,  oj  €  V  such  that  the 
control  constraints  of  oj  contain  timer  operations  which  affect  the  state  of  a  timer  read  by 
the  control  constraints  ofoy 


Values  on  a  timer  dependency  edge  can  be  modeled  precisely  in  the  same  way  as 

values  on  a  data  stream.  A  datajtuple  on  a  timer  dependency  edge  can  be  viewed  as  a  tuple 

containing  the  following  for  each  of  the  tuple  components: 

v:  A  pair  (c,  t)  containing  the  operation  c  €  (Start,  Stop,  Reset)  that  last  changed 
the  state  of  the  timer  and  the  value  t  of  the  timer  at  the  time  of  the  state  change. 
op:  The  id  of  the  operator  which  last  changed  the  state  of  the  timer. 
tw:  The  time  of  the  last  state  change. 
tr:  The  time  that  op  read  its  input  streams  before  the  firing 
that  produced  the  state  change  in  v. 

1 A  fully  expanded  PSDL  implementation  graph  is  one  in  which  every  vertex  represents  an  atomic  operator. 
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For  example,  consider  the  data-tuple  [(start,  25),  p,  36, 34]  on  the  timer  stream 

* 

Timer  1.  In  this  example,  the  v  element  of  the  data  tuple  is  the  pair  (start,  25),  the  op 
element  is  p,  the  write_time  is  36,  and  the  reacLtime  is  34.  This  means  that  the  operator  p 
read  its  streams  at  time  34,  started  the  timer  Timer 1  at  time  36,  and  the  current  value  of 
the  timer  when  the  state  change  was  executed  was  25.  This  view  of  timer  dependency  edges 
allows  us  to  treat  them  the  same  as  any  other  edge  in  the  graph. 

Top  level  prototypes  do  not  contain  inputs  or  outputs,  so  there  will  always  be 
vertices  which  do  not  write  to  a  stream.  Since  we  construct  our  slices  from  sets  of  streams 
and  not  from  vertices,  as  in  slicing  of  while  programs,  these  vertices  could  never  be  included 
in  a  slice.  The  external  vertex  is  added  to  provide  a  way  to  capture  these  vertices  during 
slicing.  During  construction  of  the  PDG  for  a  prototype,  an  artificial  edge  is  added  to  the 
graph  from  any  vertex  which  does  not  write  to  an  output  stream  to  the  external  vertex 
EXT.  These  edges  are  then  considered  in  the  construction  of  the  slices  of  the  prototype, 
thus  allowing  those  terminal  vertices  an  opportunity  to  be  included.  Only  one  external 
vertex  is  needed  for  this  graph,  because  each  artificial  edge  added  is  given  a  unique  name, 
and  considered  separately  in  the  construction  of  the  slice. 

2.  Slicing  Theorem 

A  slice  of  a  PSDL  prototype  is  defined  in  terms  of  the  prototype’s  dependence 
graph.  It  contains  the  portion  of  the  prototype  which  affects  the  history  of  a  set  of  streams. 
This  is  useful  in  isolating  changes  made  to  a  base  version  of  a  prototype  in  a  modification. 
If  the  slices  of  two  versions  with  respect  to  the  same  set  of  streams  are  different,  then  there 
are  significant  changes  that  have  been  made  to  one  version  and  not  the  other. 

Informally,  a  slice  is  an  upstream  closure  of  a  set  of  edges  in  the  graph  that  includes 
all  the  source  nodes  for  the  edges  in  the  slice.  A  formal  definition  of  a  slice  follows: 
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Definition  5  Slice  of  a  PSDL  Proto 


A  slice  Sp(X)  of  a  PSDL  prototype  P  with  respect  to  a  set  of  data  streams  X  is 
the  subgraph  ( V,E,C )  of  the  PDG  Gp  where: 

(1)  V  is  the  smallest  set  that  contains  all  vertices  oj  £  Gp  that  satisfy  at  least  one 
of  the  following  conditions: 

a)  0}  writes  to  one  of  the  data  streams  in  X. 

b )  oj  precedes  oj  in  Gp,  and  oj  €  V. 

(2)  E  is  the  smallest  set  that  contains  all  of  the  edges  €  Gp  which  satisfy  at 
least  one  of  the  following  conditions: 

a )  xk  €  X* 

b)  Xfc  is  directed  to  some  oj  €  V. 

(S)  C  is  the  smallest  set  that  contains  all  of  the  timing  and  control  constraints 
associated  with  each  operator  in  V  and  each  data  stream  in  E. 

Example  7  Figure  4-4  shouts  a  prototype  for  a  fish  farm  control  system  called  Fishies. 
Figures  4-5,  4-6  and  4-7  display  different  slices  o/Fishies. 


Theorem  3  Slicing  Theorem  for  PSDL  Prototypes: 


Let  Sp(X)  be  the  slice  of  a  prototype  P  with  respect  to  a  set  of  streams  X.  Then 
Sp(X)  and  P  have  the  same  behavior  on  any  subset  of  the  streams  in  Sp(X). 


The  proof  of  this  theorem  is  contained  in  Appendix  C,  Section  2.  The  significance 
of  this  theorem  is  that  a  slice  captures  a  fragment  of  the  semantic  behavior  of  a  prototype, 
and  the  behavior  captured  by  that  slice  remains  the  same  even  if  that  slice  is  made  a  part  of 
a  different  prototype,  provided  that  it  is  also  a  slice  with  respect  to  that  new  prototype.  This 
property  is  the  basis  for  constructing  a  change  merging  operation  that  can  provide  semantic 
guarantees  of  correctness. 


Figure  4.4:  Fish  Farm  Control  System,  Fishiest 


Figure  4.5:  (02,  NH 3,  H20) 
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Figure  4.6:  ,  {Drain Setting) 


Figure  4.7:  l  ( Drain-Setting ,  Inlet-Setting) 


C.  A  SLICING  METHOD  FOR  CHANGE-MERGING  PSDL 
PROTOTYPES 

Our  change-merging  method  for  PSDL  prototypes,  illustrated  in  Figures  4.12  through 
4.15  on  the  prototype  versions  originally  introduced  in  Chapter  III  and  shown  again  in 
Figures  4.4,  4.8  and  4.9  uses  prototype  slicing  to  determine  automatically  which  parts  of  the 
prototype  have  been  affected  by  a  change  and  which  parts  have  been  preserved. 


If  the  slice  of  &  dunged  version  of  a  prototype  with  respect  to  a  stream  present  in 
both  the  base  version  and  the  modified  version  is  different  than  the  same  slice  of  the  base 
version,  then  the  behavior  on  that  slice  is  likely  to  be  different.  Therefore  that  change  is 
significant,  and  must  be  preserved  in  the  merged  version.  For  example,  consider  the  slice 
of  Fishiesi.i  with  respect  to  the  stream  Adivatt-Drain,  illustrated  in  Figure  4.10,  and  the 
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same  slice  of  Fishiesi.*  illustrated  in  Figure  4.11.  It  is  easy  to  see  a  portion  of  the  effect  of 
the  change  which  produced  Fishies\ j  from  Fishies  1.1.  If  we  were  to  take  the  same  slice  of 
Fishiest.*  we  would  discover  that  it  is  identical  to  the  slice  of  the  base  version  of  Fishies. 
This  illustrates  that  this  part  of  the  Fishies  prototype  is  not  affected  by  the  change  which 
produced  Fishies**  Since  this  change  is  significant,  it  must  be  reflected  in  the  merged 
version. 


Figure  4.10:  Spuhiui.1  {ActivateJDrain) 


Slices  are  important  because  they  capture  all  of  the  parts  of  a  program  that  can  affect 
the  behavior  visible  in  a  set  of  data  streams.  If  two  different  programs  have  the  same  slice  for 
a  set  of  streams,  they  also  have  the  same  behavior  over  that  set  of  streams.  The  preserved 
part  of  a  prototype  is  then  the  largest  set  of  streams  that  have  the  same  single  stream  slice 
in  all  three  versions,  and  the  affected  streams  of  each  modification  are  those  that  have  a 
different  single  stream  slice  in  the  modified  version  than  in  the  base  version.  Performing 
a  change-merge  using  Fishies\.\  as  the  base  version,  and  Fishies  u  and  Fishies*t  as  the 
modified  versions,  we  get  the  preserved  part  as  shown  in  Figure  4.12  and  affected  parts  as 
shown  in  Figures  4.13  and  4.14. 


Figure  4.11:  SFUkiuta(J ictivatcJ^rain) 


Figure  4.12:  Preserved  Parts  of  Fishiesui  in  Both  Modifications 


Figure  4.13:  Affected  Part  of  Fiskies j. 2 


Figure  4.14:  Affected  Part  of  Fishies2.2 


77 


1b  constructing  the  preserved  part,  we  consider  each  stream  individually,  taking  the 
slice  of  each  version  with  respect  to  that  stream.  If  the  slices  are  the  same,  then  that  slice 
is  added  to  the  preserved  part.  After  all  streams  have  been  t  eked,  the  preserved  part  is 
complete. 

The  affected  parts  are  constructed  by  comparing  the  slices  of  each  stream  in  the  modified 
version  against  the  same  slice  of  the  base  version.  The  stream  is  included  in  the  affected 
part  if  the  slices  are  different. 

The  merged  version  is  formed  by  taking  the  union  of  the  preserved  part  of  all  three 
versions  and  the  affected  parts  of  the  two  modified  versions.  If  the  slice  of  the  merged  version 
with  respect  to  the  streams  affected  by  each  modification  is  the  same  as  the  corresponding 
slice  of  the  modified  version,  then  semantic  correctness  of  the  merged  version  with  respect 
to  the  modifications  is  established.  The  result  of  change-merging  Fishicsi.i,  Fishiest  and 
Fishiest  is  shown  in  Figure  4.15. 

Our  slicing  method  has  the  advantage  of  a  clear  semantic  criterion  for  correctness,  and 
the  disadvantage  of  reporting  conflicts  whenever  two  changes  can  affect  the  same  stream, 
regardless  of  whether  there  exists  a  computation  history  in  which  the  two  changes  actually 
interact  or  conflict  with  each  other. 


78 


Figure  4.15:  The  Change-Merged  Version  of  the  Fishies  Prototype. 


V.  CHANGE-MERGE  ALGORITHM 


FVom  the  change-merging  models  for  both  the  specification,  shown  in  Chapter  III,  and 
the  implementation,  shown  in  Chapter  IV,  we  developed  a  change-merging  algorithm.  This 
change-merging  algorithm  takes  advantage  of  the  fact  that  the  specification  and  implemen¬ 
tation  can  be  change-merged  separately  to  create  a  correctly  change-merged  program.  This 
chapter  outlines  the  change-merging  algorithm  in  detail  and  provides  a  piece  by  piece  analy¬ 
sis  of  the  algorithm  for  correctness,  complexity  and  coverage.  This  algorithm  was  written  to 
accept  a  base  version  and  two  modifications  as  input.  It  is  easily  extended  to  change-merge 
the  result  of  n  modifications  to  a  base  version  by  applying  the  algorithm  iteratively  using 
the  result  of  the  most  recent  application  as  one  input  and  the  next  modification  as  the  other. 
The  result  of  a  successful  iterative  application  on  n  versions  is  a  merged  version  containing 
the  significant  behaviors  of  each  of  the  inputs. 

The  algorithm  changejmcrge  accepts  three  expanded  versions  of  a  PSDL  program  as 
input.  It  then  extracts  all  of  the  PSDL  components  from  each  version  of  the  program. 
The  atomic  components  are  held  in  storage  to  be  included  in  the  change-merged  version 
of  the  program  if  needed,  and  the  composite  component  of  each  program  is  divided  into  a 
specification  part  and  an  implementation  part. 

Each  of  these  parts  are  change-merged  separately  and  the  results  are  recombined  to  cre¬ 
ate  the  change-merged  composite  component.  From  the  implementation  part  of  the  change- 
merged  composite  component,  the  algorithm  can  deduce  which  of  the  atomic  components 
need  to  be  included  in  the  change-merged  program.  The  change-merged  program  is  then  re¬ 
turned.  If  a  conflict  is  detected  during  the  change-merging  process,  the  CONFLICT  variable 
is  set  to  true,  and  a  flag  is  placed  into  the  change-merged  program  at  the  location  of  the 
conflict  to  aid  the  designer  in  locating  and  resolving  it.  Figure  5.1  shows  the  change-merge 
algorithm. 
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Algorithm  change_merge( BAS E ,  A,  B :  in  psdLprogram;  CONFLICT  :  out  boolean) 
return  psdLprogram 
begin 

1.  Extract  the  psdl .components  from  each  of  the  input  psdLprograms. 

2.  Change-merge  the  specification  parts  for  the  three  input  composite  components. 

a.  Change-merge  the  state  declarations. 

b.  Change-merge  the  exception  declarations. 

c.  Change-merge  the  maximum  execution  times. 

d.  Change-merge  the  formal  and  informal  descriptions. 

3.  Change-merge  the  implementation  parts  for  the  three  input  composite  components. 

a.  Create  the  prototype  dependency  graphs  for  each  version. 

b.  Create  the  affected  parts  of  each  modified  version. 

c.  Create  the  preserved  part  of  the  base  in  all  three  versions. 

d.  Change-merge  the  graphs. 

e.  Change-merge  the  stream  declarations. 

f.  Change-merge  the  timer  declarations. 

g.  Change-merge  the  control  constraints. 

(1)  Change-merge  the  trigger  constraints. 

(2)  Change-merge  the  execution  guard  constraints. 

(3)  Change-merge  the  periods. 

(4)  Change-merge  the  fmish_withins. 

(5)  Change-merge  the  minimum  calling  periods. 

(6)  Change-merge  the  maximum  response  times. 

(7)  Change-merge  the  output  guard  constraints. 

(8)  Change-merge  the  exception  trigger  constraints. 

(9)  Change-merge  the  timer  operations. 

4.  Create  the  change-merged  program. 

a.  Combine  the  change-merged  specification  and  implementation. 

b.  From  the  resulting  implementation,  determine  which  of  the  atomic  components 
from  each  of  the  input  versions  is  to  be  included  in  the  change-merged  program. 

5.  Return  the  change-merged  program, 
end  Change  .Merge; 


Figure  5.1:  Algorithm  changcjncrgc. 
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A.  EXTRACTING  THE  COMPONENTS 


Extracting  the  components  from  each  of  the  input  PSDL  programs  is  done  using  a 
map  fetch  operation.  The  algorithm  loops  through  each  of  the  input  programs  and  retrieves 
the  set  of  components  each  one  contains.  The  atomic  components  are  placed  in  a  holding 
program  so  they  can  be  retrieved  later  if  needed  for  the  merged  program,  and  the  composite 
component  is  extracted  for  change-merging.  The  algorithm  fragment  used  to  extract  the 
components  is  shown  in  Figure  5.2. 


a.  For  every  component  in  the  Base  Version  loop 

(1)  Fetch  the  component; 

(2)  If  the  component  is  atomic  then  bind  to  holding  program  for  base  version; 

(3)  else  extract  the  component;  end  if;  end  loop; 

b.  For  every  component  in  the  A  Version  loop 

(1)  Fetch  the  component; 

(2)  If  the  component  is  atomic  then  bind  to  holding  program  for  base  version; 

(3)  else  extract  the  component;  end  if;  end  loop; 

c.  For  every  component  in  the  B  Version  loop 

(1)  Fetch  the  component; 

(2)  If  the  component  is  atomic  then  bind  to  holding  program  for  base  version; 

(3)  else  extract  the  component;  end  if;  end  loop; 


Figure  5.2:  Algorithm  fragment  for  Extracting  the  Component. 


The  extraction  part  of  the  algorithm  requires  a  loop  through  the  components  of  each 
version  to  perform  the  fetch.  The  correctness  of  this  algorithm  fragment  can  be  shown  using 
simple  induction.  Since  the  operations  inside  the  loop  are  constant  and  the  loop  is  executed 
only  once  for  each  component  of  each  program,  the  worst-case  complexity  of  this  part  of  the 
algorithm  is  O(n),  where  n  is  the  number  of  components  in  the  program.  This  algorithm 
fragment  can  be  used  for  all  fully  expanded  PSDL  programs,  since  they  contain  only  one 
composite  component. 
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B.  CHANGE-MERGING  THE  SPECIFICATIONS 


Change-merging  the  specification  of  the  top  level  component  requires  five  operations. 
The  five  operations  are  responsible  for  change-merging  the  components  of  the  specification: 
the  state  declarations,  the  maximum  execution  times,  the  exception  sets,  and  the  informal 
and  formal  descriptions. 

1.  Change-Merging  the  State  Declarations 

Change-merging  the  state  declarations  is  done  with  the  procedure  merge  ^states. 
Since  the  state  declarations  are  a  set,  normal  set  operations  may  be  used  to  merge  the  state 
declarations  themselves,  but  the  initial  values  of  the  state  variables  conform  to  a  flat  lattice 
structure  and  any  change  must  be  preserved.  The  algorithm  mergejstates  is  shown  in  Figure 
5.3. 


To  show  correctness  of  mergejstates ,  we  must  show  that  it  correctly  implements 
the  equation  ( A  —  Base)  U(Ar\B)U(B—  Base).  Two  internal  loops  construct  this  equation. 
The  first  loop  captures  any  state  variable  declaration  which  appears  in  A ,  but  not  in  BASE ; 
the  ( A  —  Base)  part  of  the  equation,  and  then  captures  any  state  variable  declaration  which 
appears  in  both  of  the  modified  versions;  the  ( A  Cl  B)  part  of  the  equation.  The  second 
loop  captures  any  state  variable  declaration  which  appears  in  B,  but  not  in  BASE ;  the 
(B  —  Base)  part.  Since  both  loops  add  state  variable  declarations  to  the  same  set  MERGE , 
the  union  part  of  the  equation  is  satisfied. 

The  execution  of  mergejstates  requires  a  membership  test  and  add  operation  for 
every  state  declared,  and  these  are  both  linear  time  operations  with  the  current  linked-list 
implementation  of  sets.  Thus  the  entire  algorithm  requires  0(s3)  time,  where  s  is  the  number 
of  states  declared.  This  can  be  improved  to  O(slogs)  if  balanced  trees  are  used  for  the  sets. 


Algorithm  mergejatatts^MERGE :  in  out  type-declaration; 

BASE ,  A,  B:  in  type-declaration ; 

MERGE JN IT:  in  out  initjtnap; 

AJNIT,  BJNIT:  in  initjnap) 

begin 

for  every  state  variable,  s,  declared  in  A 
if  s  is  not  in  BASE ,  and  s  is  not  in  B  then 

add  s  to  MERGE;  add  initial  value  to  MERGE  JN  IT; 
end  if; 

if  s  is  in  B  then 
add  to  MERGE; 

if  the  initial  values  are  the  same  in  AJNIT  and  BJNIT  then 
add  initial  value  to  MERGEJNIT; 
else  add  conflict  .expression  to  MERGEJNIT; 
end  if; 
end  if; 
end  loop; 

for  every  state  variable,  s,  declared  in  B 
if  s  is  not  in  BASE  and  s  is  not  in  A  then 

add  to  MERGE;  add  initial  value  to  MERGEJNIT; 
end  if; 
end  loop; 

end  mergc^states; 

Figure  5.3:  Algorithm  mergutatcs. 
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2.  Change-Merging  the  Maximum  Execution  Times 


Change-merging  the  maximum  execution  time  constraints  is  done  with  the  function 
mergcjmci,  shown  in  Figure  5.4.  Maximum  execution  times  follow  a  Brouwerian  Algebra 
structure  as  shown  by  Proposition  2  in  Chapter  III,  Section  D.2,  and  must  be  merged  ac¬ 
cording  to  those  rules. 


Algorithm  mergejmet(BASE ,  A,  B :  millisec)  return  millisec 
AJDIFFJBASE,  B-DIFF-BASE,  AJNTJ3:  millisec; 
begin 

if  A  <  B  then 
AJNT.B  :=  B; 
else  AJNTJB  :=  A; 
end  if; 

if  BASE  <  A  then 
A-DIFFJJASE  :=  X; 
else  AJDIFFJBASE  :=  A; 
end  if; 

if  BASE  <  B  then 
B-D1FF-BASE  :=  X; 
else  B-DIFF.BASE  :=  B; 
end  if; 

if  AJDIFFJIASE  <  AJNTJB  then 

if  AJ)IFF-BASE  <  BJDIFF.BASE  then 
return  AJDIFFJBASE ; 
else  return  BJDIFFJ3ASE ; 
end  if; 

else  if  AJNTJB  <  BJ)IFF-BASE  then 
return  AJNTJB ; 
else  return  BJ)IFFJBASE\ 
end  if; 
end  if; 

end  mergejmet ; 


Figure  5.4:  Algorithm  mergejmet. 

The  algorithm  for  change-merging  maximum  execution  times  must  also  satisfy  the 
change-merging  equation  (A  —  Base)  U  (A  n  B)  U  (B—  Base).  It  uses  a  series  of  conditional 
expressions  to  calculate  the  values  of  AJ)IFFJBASE ,  BJ)IFFJ3ASE ,  and  AJNTJB , 
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which  represent  the  (A  —  Bast),  ( B  —  Bast)  and  APIA  parts  of  the  equation  shown  above. 
It  then  combines  them  according  to  the  rules  outlined  in  Chapter  III,  Section  D.2.  This 
adherence  to  the  mathematical  model  guarantees  the  correctness  of  the  algorithm.  Since 
this  algorithm  contains  no  loops,  it  requires  constant  time  to  execute,  so  the  worst-  rase  time 
complexity  of  mergejnet  is  0(1). 

3.  Change-Merging  the  Exception  Declarations  and  Keywords 

Change-merging  the  exception  declarations  and  the  keyword  sets  is  done  using 
the  mergt-icLstts  function  shown  in  Figure  5.5.  This  algorithm  calculates  the  equation 
(A  —  Base)  U(AnA)U(B-  Base)  in  precisely  the  same  way  as  mcrgejstates  calculates 
the  merge  of  the  state  declarations  without  the  initial  values. 

Algorithm  mergt-id.seis(BASE,  A ,  B :  idjset)  return  i<Lstt 
begin 

Calculate  A  —  BASE. 

Calculate  B  —  BASE. 

Calculate  Af)#- 

Return  (A  -  BASE)  \J(Af)B) \J(B  -  BASE). 
end  mergeJdjsets ; 

Figure  5.5:  Algorithm  rnergc-icLsets. 

The  correctness  and  complexity  analyses  of  mergeAdjsets  are  identical  to  those  of 
merge- states,  so  merging  idjsets  requires  worst  case  0(x3)  time  for  exception  declarations 
and  0{h?)  time  for  keywords. 

4.  Change-Merging  the  Descriptions 

Change-merging  both  the  informal  and  the  formal  descriptions  is  accomplished 
using  the  function  merge Jer*  shown  in  Figure  5.6.  mergeJext  implements  a  fiat  lattice 
change-merge,  and  any  change  :rom  the  base  version  in  one  modification  must  be  identical  to 
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Algorithm  mergeJext  (BASE,  A ,  B :  text)  return  text 
begin 

if  BASE  «  A 
then  return  B 
else  if  BASE  =  B 
then  return  A 
else  if  A  =  B 
then  return  A 

else  return  (“Conflict  in  text.  Must  be  change-merged  manually!”) 
end  if; 
end  if; 
end  if; 

end  mergeJext ; 


Figure  5.6:  Algorithm  mergeJext. 

5.  Analysis  of  Specification  Change-Merge 

Correctness  of  the  specification  change-merge  part  of  the  algorithm  is  guaranteed 
by  the  correctness  of  the  individual  algorithms  which  make  up  the  specification  change- 
merge.  The  worst-case  time  complexity  of  the  specification  part  of  the  algorithm  is  obtained 
fay  adding  the  complexities  of  the  individual  parts  as  follows: 

0(3 3)  +  0(*3)  +  0(1?)  +  0(1)  +  0(1)  +  0(1)  =  0(s3  +  z3  +  it3) 

where  s  is  the  number  of  state  declarations,  x  is  the  number  of  exception  declarations,  and 
k  is  the  number  of  keywords. 

This  algorithm  is  capable  of  performing  change-merge  operations  on  all  PSDL 
operator  specifications. 
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C.  CHANGE-MERGING  THE  IMPLEMENTATIONS 


Change-merging  the  implementation  parts  is  also  accomplished  by  change-merging  the 
individual  parts  of  the  implementation  separately.  It  requires  five  main  operations;  change¬ 
merging  the  graphs,  change-merging  the  stream  declarations,  change-merging  the  timer  dec¬ 
larations,  change-merging  the  control  constraints,  and  change-merging  the  informal  descrip¬ 
tions. 


1.  Change-Merging  the  Graphs 

To  change-merge  the  PSDL  implementation  graphs,  we  must  first  convert  them  to 
prototype  dependency  graphs  that  accurately  reflect  all  of  the  timer  dependencies  between 
operators  in  the  prototype  as  well  as  the  data  dependencies.  We  do  this  with  the  build -PDG 
function  shown  in  Figure  5.7.  Next  we  must  construct  the  preserved  and  affected  parts  of 
the  three  input  graphs  according  to  the  slicing  rules  defined  in  Chapter  IV.  The  algorithms 
for  these  constructions  are  contained  in  Figures  5.9  and  5.8,  respectively.  Finally,  we  must 
combine  these  three  parts  into  a  change-merged  prototype  dependency  graph  using  a  graph- 
union  operation,  shown  in  Figure  5.12. 

In  building  the  prototype  dependency  graph,  builcLPDG  adds  an  external  vertex, 
EXT ,  to  the  prototype  implementation  graph,  then  for  every  vertex  with  no  outputs,  it 
creates  an  edge  from  that  vertex  to  EXT.  This  is  necessary  to  ensure  that  these  terminal 
vertices  are  included  in  the  slices,  since  slices  are  constructed  based  on  edges  not  vertices. 
Then  for  every  timer  declaration  in  the  prototype  implementation,  build-PDG  creates  an 
edge  from  every  vertex  which  affects  the  state  of  that  timer  to  every  vertex  which  reads  its 
value. 


The  algorithm  build-PDG  contains  two  loops.  The  first  loop  iterates  through  the 
vertices  in  the  graph,  and  determines  if  the  vertex  has  any  outputs.  For  every  vertex  with 
no  outputs,  the  algorithm  then  adds  an  edge  to  the  graph  from  that  vertex  to  the  artificial 
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Algorithm  bmULPDG(P  :  psds  component)  return  pr  doty pejdepcndency  .graph 
O :  prototype jiependency^raph; 

O :  vertex; 
source,  dest :  itLsct ; 

begin 

G graph(P); 

add  external  vertex,  EXT; 

for  every  terminal  vertex,  O,  add  an  edge  from  0  to  EXT ; 
for  every  timer  declaration  in  the  implementation  of  P  loop 
initialize  source  and  dest  to  empty. 

add  every  vertex  which  affects  the  state  of  the  timer  to  source; 
add  every  vertex  which  reads  the  timer  to  dest; 
add  an  edge  to  G  from  every  vertex  in  source  to  every  vertex  in  dest; 
end  loop; 
return  G; 
end  buildJPDG; 


Figure  5.7:  Algorithm  buildJPDG. 

vertex  EXT.  The  correctness  of  tins  loop  can  be  established  by  showing  that  at  the  end  of 
the  loop,  there  are  no  vertices  in  the  graph  without  output  edges,  except  EXT  Since  the 
loop  cycles  through  all  vertices  in  the  graph  and  adds  an  output  edge  to  the  graph  from  any 
vertex  which  does  not  have  one  to  EXT ,  this  proof  is  trivial. 

The  second  loop  iterates  through  the  set  of  timer  declarations,  and  builds  two 
sets  for  each  timer,  source  and  dest.  It  then  adds  an  edge  to  the  graph  from  every  vertex 
in  source  to  every  edge  in  dest.  The  source  set  contains  all  of  the  vertices  using  timer 
operations  that  affect  the  state  of  the  timer.  The  dest  set  contains  all  of  the  vertices  that 
read  the  value  of  the  timer. 

To  show  correctness  of  this  loop,  we  must  show  that  at  the  end  of  each  iteration 
through  the  loop,  the  graph  contains  all  timer  dependency  edges  associated  with  the  timer 
declarations  thus  far  encountered,  and  at  the  end  of  the  loop,  the  graph  contains  all  timer 
dependency  edges  associated  with  the  timer  declarations  in  the  implementation.  We  do  this 
by  the  following  induction  proof: 
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Proof: 


Basis:  Since  source  and  dost  are  initialized  at  the  beginning  of  each  iteration 
through  the  loop,  they  are  empty  before  the  first  iteration,  thus  the  graph  contains  no  timer 
dependency  edges  before  the  first  iteration. 

Induction  Hypothesis:  At  the  end  of  the  kth.  iteration,  all  timer  dependency 
edges  associated  with  the  first  k  timer  declarations  are  included  in  the  graph. 

Induction  Step:  At  the  beginning  of  the  k  +  1st  iteration  of  the  loop,  the  source 
and  dost  sets  are  reinitialized  to  empty.  The  vertices  that  affect  the  state  of  the  k  +  1st 
timer  are  added  to  source ,  and  the  vertices  that  read  the  value  of  the  k  +  1st  timer  are 
added  to  dost.  Now,  for  every  vertex  in  source ,  the  algorithm  adds  an  edge  to  every  vertex 
in  dest.  Thus  at  the  end  of  the  Jb  +  1st  iteration,  the  graph  contains  all  timer  dependency 
edges  associated  with  the  first  k  timer  declarations,  by  the  induction  hypothesis,  plus  it  now 
contains  all  timer  dependency  edges  associated  with  the  k+  1st  timer  declaration.  Thus,  we 
can  conclude  that  for  any  number  n  of  timer  declarations,  at  the  end  of  the  nth  iteration 
of  the  loop,  the  graph  contains  all  timer  dependency  edges  associated  with  the  first  n  timer 
declarations.  □ 

The  complexity  of  this  algorithm  is  determined  by  the  sum  of  the  complexities 
of  the  two  loops.  Since  the  first  loop  iterates  through  all  vertices  in  the  graph,  performing 
worst-case  linear  operations  on  each  iteration,  its  worst  case  time  complexity  is  ©(n3),  where 
n  is  the  number  of  vertices  in  the  graph,  excluding  EXT.  The  second  loop  contains  three 
inner  loops  that  iterate  through  the  vertex  set  of  the  graph.  The  first  two  of  these  inner 
loops  contain  worst-case  linear  operations.  The  third  inner  loop  contains  another  inner  loop 
that  could  also  possibly  iterate  through  all  vertices  in  the  graph,  making  its  worst  case 
time  complexity  ©(n3).  Thus,  the  worst  case  time  complexity  of  the  second  outer  loop  is 
0(tn*),  where  t  is  the  number  of  timer  declarations  contained  in  the  implementation  and 
n  is  the  number  of  vertices  in  the  graph.  The  algorithm  then  contains  two  loops,  one  with 
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complexity  C?(n*),  and  one  with  complexity  C?(in*),  therefore,  the  worst  case  time  complexity 
of  buiULPDG  is  0(tn*). 

The  next  step  in  change-merging  the  graphs  is  finding  out  the  parts  of  the  mod¬ 
ified  versions  which  are  different  from  the  base.  This  is  accomplished  using  the  algorithm 
af  fectedjpart,  shown  in  Figure  5.8.  This  algorithm  returns  the  set  of  edges  in  the  modified 
version  for  which  the  slice  of  the  modified  version  is  different  than  the  slice  of  the  base  ver¬ 
sion.  First,  each  edge  in  the  modified  version  is  checked  to  see  if  it  is  the  base  version.  If  it 
is  not,  then  it  is  added  to  the  affected  part.  Next,  the  algorithm  checks  to  see  if  the  edge 
recieves  input  from  different  sources  in  the  modified  version  than  in  the  base  version.  If  the 
sources  are  different,  then  the  edge  is  added  to  the  affected  part.  Finally,  the  algorithm  adds 
any  edge  to  the  affected  part  which  receives  input  via  an  edge  already  in  the  affected  part. 

It  is  sufficient  to  include  in  the  affected  part  of  modified  version,  only  those  edges 
which  are  different  in  the  modified  and  base  versions  of  the  graph,  and  the  edges  which  follow 
them.  Any  edge  which  precedes  an  affected  edge  will  produce  the  same  slice  in  both  versions 
since  slices  are  constructed  backward  from  the  edge.  The  correctness  of  off ed.ed.part  is 
established  by  showing  that,  every  in  edge  in  Slice  produces  a  slice  which  is  different  in  both 
G  and  B.  We  prove  this  by  an  induction  over  the  while  loop. 

EEfifi f: 

Basis:  At  the  beginning  of  the  first  iteration  of  the  loop,  Slice  gets  one  edge  from 
E  which  is  either  in  G  and  not  in  B,  or  is  written  to  by  a  different  set  of  vertices  in  G  and 
B.  This  edge  will  certainly  produce  a  different  slice  in  the  two  graphs,  so  Slice  contains  only 
edges  which  produce  different  slices  in  G  and  B. 

Induction  Hypothesis:  After  the  first  k  iterations  of  the  loop,  every  edge  in 
Slice  produces  a  different  slice  in  G  than  in  B. 
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Algorithm  af  fcde<Lpart(G,  B  :  prctctypcjlependency .graph) 
return  edge^et 
Slice ,  C,D,E  :  edgejset] 
x,y :  edge] 
begin 

C edges(B)] 

D  :=  edgea(G)] 

E:—dif  fcrencc(D,  C)\ 
for  every  edge  x  in  D  loop 

if  sources(x)  in  G  are  different  from  the 
sour-'*s(x)  in  B  then 
add  x  to  E] 
end  if; 
end  loop; 

while  E  not  empty  loop 

select  and  remove  an  edge  x  from  E; 

add  x  to  Slice] 

for  each  edge  y  €  D  loop 

if  x.dcstination  g  aources(y,  G)  then 
add  y  to  E; 
remove  y  from  D; 
end  if; 
end  loop; 
end  loop; 
return  Slice] 
end  af fectedLpart] 


Figure  5.8:  Algorithm  af fededjpart 
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Induction  Step:  During  the  Jbth  iteration  of  the  loop,  every  edge  in  G  which 
follows  the  ibth  edge  added  to  Slice  in  the  data  flow  of  G  is  added  to  E.  At  the  beginning 
of  the  k  +  1st  iteration  of  the  loop,  one  of  the  edges  in  E  is  removed  from  E  and  added 
to  Slice.  Since  we  know  that  any  edge  which  follows  an  affected  edge  in  the  data  flow  will 
certainly  produce  a  different  slice  in  G  and  B,  we  know  that  this  edge  will  as  well.  Thus  by 
the  induction  hypothesis,  all  of  the  elements  in  Slice  before  this  iteration  produced  different 
slices  in  G  and  B,  and  the  current  iteration  adds  an  edge  which  produces  a  different  slice 
in  G  and  B,  therefore  after  the  k  +  1st  iteration  of  the  loop,  every  edge  in  Slice  produces  a 
different  slice  in  G  and  B.  Since  E  is  a  finite  set,  and  no  edge  already  in  Slice  can  be  added 
back  into  £,  the  loop  will  terminate.  □ 

The  complexity  of  af  f ededbpart  is  determined  by  the  complexity  of  the  loops 
inside.  The  first  for  loop  iterates  over  all  of  the  edges  in  the  input  graph,  G,  and  adds  any 
edge  to  E  which  is  different  in  G  and  B  or  redeves  input  from  different  sources  in  G  and 
B.  The  worst-case  time  complexity  of  this  loop  is  0(e  *  n),  where  e  is  the  number  of  edges 
in  G  and  n  is  the  number  of  vertices  in  G.  The  second  while  loop  iterates  over  all  of  the 
edges  in  E,  which  we  know  to  contain  at  most  the  edges  of  (?,  and  any  edge  which  follows 
this  edge  in  G  is  added  to  E.  This  makes  the  worst-case  time  complexity  of  this  loop,  0(e7). 
Therefore  the  worst-case  time  complexity  of  af  f  ectecLpart  is  0(e7)t  where  e  is  the  number 
of  edges  in  G. 

The  next  step  in  change-merging  the  graphs  is  constructing  the  part  of  the  base 
version  that  is  preserved  in  both  of  the  modifications.  This  is  done  using  the  algorithm 
preserved jpart  shown  in  Figure  5.9.  This  algorithm  loops  over  all  of  the  edges  in  Base  and 
checks  to  see  if  they  are  in  the  affected  parts  of  either  modification,  or  have  been  removed 
in  one  of  the  modifications.  If  the  edge  is  not  in  either  affected  part  and  it  is  in  both 
modifications,  then  the  slice  it  produces  is  the  same  in  all  three  versions  and  it  is  added  to 
the  preserved  part. 
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Algorithm  preserved j>ari(BASE ,  A ,  APA ,  B,  APB :  prototype  Jiependency.gr aph) 
return  edgejset 
PP  :  edgejset  :=  empty  jset\ 
e :  edge; 
begin 

for  every  edge  E  in  edges(BASE)  loop 

if  not  e  €  APA  U  APB  and  e  €  edges(A)  D  edges(B) 
then  add  e  to  PP; 
endif; 
end  loop 
return  PP; 
end  prcscrvecLpart-, 


Figure  5.9:  Algorithm  preservedpart 

Only  those  edges  which  appear  in  all  three  versions  and  are  not  part  of  either 
affected  part  are  added  to  the  preserved  part.  The  correctness  of  this  algorithm  is  established 
by  showing  that  after  each  iteration  of  the  for  loop,  PP  only  contains  edges  which  will 
produce  the  same  slice  in  all  three  versions.  We  offer  the  following  proof: 

Basis:  Before  the  first  iteration  of  the  loop,  PP  is  empty.  Since  the  slice  with 
respect  an  empty  edge  is  an  empty  graph,  this  slice  is  certainly  the  same  in  all  three  versions. 

Induction  Hypothesis:  After  the  first  k  iterations  of  the  loop,  every  edge  in  PP 
produces  the  same  slice  in  all  three  versions  of  the  graph. 

Induction  Step:  During  the  k  +  1st  iteration  of  the  loop,  if  the  edge  e  is  in  the 
edge  sets  of  all  three  versions,  and  it  is  not  contained  in  an  affected  part,  then  it  was  not 
affected  nor  removed  by  either  version,  thus  it  is  preserved  in  all  three  versions.  Since  after 
the  fcth  iteration  of  the  loop,  all  of  the  edges  in  PP  produced  slices  which  were  the  same 
in  all  three  versions,  and  the  k  +  1st  iteration  adds  another  which  produces  the  same  slice 
in  all  three  versions,  after  k  + 1  iterations,  every  edge  in  PP  produces  the  same  slice  in  all 
three  versions.  Therefore  the  correctness  of  preservedLpart  is  established.  □ 
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The  complexity  of  preservctLpart  is  determined  by  the  complexity  of  the  for  loop. 
Since  ell  of  the  operations  inside  of  the  loop  are  at  worst  0(e)  operations,  and  the  loop 
iterates  once  for  every  edge  in  the  base  version  of  the  graph,  the  worst-cast  time  complexity 
of  preservedjpart  is  0(eJ),  where  e  is  the  number  of  edges  in  BASE. 


Once  the  preserved  part  of  the  base  and  the  affected  parts  of  both  modified  versions 
have  been  calculated,  the  slices  produced  by  these  sets  can  be  change-merged  into  a  single 
graph.  The  slices  are  constructed  using  the  algorithm  creates  lice  shown  in  Figure  5.10. 
This  algorithm  takes  a  graph  and  an  edge  as  input  and  constructs  the  slice  backward  from 
the  edge,  according  to  the  definition  for  a  slice  given  in  Chapter  IV,  Section  B.2. 


Algorithm  create^lice(G :  prototypejicpcndencyjjraph ;  E  :  edge) 
return  prototype  jdependency  .graph 
S  :  prototype  jdependency  jgraph’, 

V :  vertex jset; 
w :  vertex ; 
begin 
if  e  in  G 

then  add  e  to  5; 
else  return  emptyjjraph ; 
end  if; 

for  every  vertex  to  in  G  loop 
if  to  writes  to  e 
then  add  to  to  V ; 
end  if; 
end  loop; 

while  V  not  empty  loop; 

select  and  remove  vertex  to  from  V; 
add  to  to  S; 

add  parents  of  to  to  V  if  not  in  5; 
add  edges  between  parents  and  to  to  5; 
end  loop; 
return  5; 
end  createjtlice ; 


Figure  5.10:  Algorithm  createjslicc 


The  correctness  of  crcatc^slicc  is  established  by  showing  that  the  algorithm  pro- 
duces  a  correct  slice  of  G  with  respect  to  E,  according  to  our  definition  of  a  slice  given  in 
Chapter  IV. 

Proof: 

If  e  is  not  an  edge  in  G,  then  ertattjslice  returns  an  empty  graph,  which  is  the 
correct  slice  of  G  with  respect  to  e.  If  e  is  an  edge  in  G,  then  e  is  added  to  the  slice,  and  any 
vertex  which  writes  to  e  is  added  to  the  set  of  vertices  V.Then  the  algorithm  iterates  over  a 
while  loop  as  long  as  V  is  not  empty.  The  correctness  of  the  while  loop  is  established  by 
showing  that  at  the  end  of  every  iteration  of  the  loop,  the  slice  S  contains  only  the  vertices 
and  edges  which  affect  the  edge  e,  and  after  the  last  iteration  of  the  loop,  S  contains  all  of 
the  vertices  and  edges  in  G  which  affect  the  edge  e. 

Basis:  Before  the  first  iteration  of  the  loop,  the  only  edge  in  S  is  e,  and  certainly 
every  edge  in  S  affects  e. 

Induction  Hypothesis:  After  the  kih  iteration  of  the  loop,  all  of  the  edges  and 
vertices  in  S  affect  the  values  written  to  e. 

Induction  Step:  During  the  k  +  1st  iteration  of  the  loop,  a  vertex  w  is  removed 
from  V  and  added  to  S.  Since  only  those  vertices  which  write  to  an  edge  in  5  are  in  V,  and 
only  edges  which  affect  the  values  written  to  e  are  in  S  by  the  Induction  Hypothesis,  we  are 
guaranteed  that  to  is  a  correct  addition  to  5.  So  after  the  k  +  1st  iteration  of  the  loop,  S 
contains  only  edges  and  vertices  which  affect  values  written  to  e. 

Since  V  contains  at  most  the  number  of  vertices  in  G,  and  one  vertex  is  removed  on 
every  iteration  of  the  loop,  we  are  assured  that  the  loop  will  terminate.  Since  during  every 
iteration,  any  edge  which  provided  input  to  a  vertex  in  S  is  added  to  S  and  every  iteration 
adds  any  vertex  which  writes  to  an  edge  in  5,  we  are  assured  that  after  the  last  iteration  of 
the  loop,  all  of  the  vertices  and  edges  which  affect  the  values  written  to  e  will  be  in  the  slice. 


The  time  complexity  of  createjslice  is  determined  by  the  two  inner  loops.  The 
for  loop  iterates  over  the  vertices  of  the  graph  one  time.  This  makes  the  worst-case  time 
complexity  of  this  loop,  O(n),  where  n  is  the  number  of  vertices  in  the  graph.  The  while 
loop  iterates  over  a  set  of  vertices,  however  through  all  of  the  iterations  of  the  loop  at  most 
each  edge  is  visited  once,  making  the  worst-case  time  complexity  of  this  loop  0(e ),  where 
e  is  the  number  of  edges  in  the  base  version  of  the  graph.  Therefore,  the  worst-case  time 
complexity  of  createjslice  is  0(n  +  e). 

Once  the  slices  are  constructed,  they  are  merged  using  the  function  grapkjmerge , 
shown  in  Figure  5.11.  This  is  a  very  simple  graph  merging  algorithm  which  uses  successive 
calls  to  graph-union ,  shown  in  Figure  5.12  to  combine  the  preserved  part  of  the  base  with 
the  affected  parts  of  both  modifications  into  a  change-merged  prototype  dependency  graph. 


Algorithm  graph  jmerge{G\ ,  (72,  (73  :  prototype-dependency -graph) 
return  prototype-dependency -graph 
(7  :  prototype  .dependency  .graph  :=  empty -psdl.gr  aph; 
begin 

G  :=s  graph-union(Gl ,  (72); 

G  :=  graphjunion(G ,  (73); 
return  (7; 
end  graph-merge; 


Figure  5.11:  Algorithm  graphjnerge 

The  graphjunion  algorithm  is  used  to  combine  two  graphs  into  one.  It  accepts  two 
prototype  dependency  graphs  as  input  and  adds  the  edges  and  vertices  of  one  to  the  other. 

The  algorithm  graphjunion  makes  use  of  two  successive  union  operations,  and 
union  operations  are  very  well  defined.  Therefore,  the  correctness  of  graphjunion  is  easily 
established. 

The  complexity  of  graphjunion  is  determined  solely  by  the  complexities  of  the 
set  union  operations,  which  are  linear  in  the  worst  case.  Therefore,  the  worst  case  time 
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Algorithm  graph  junion(G\,  G2  :  prototype jiependency^raph) 
return  prototype  -dependency  ^raph 
G  :  prototype-dependency  .graph  empty  jpsdl  .graph; 

begin 

G.vertices  :=  vertices(Gl)  U  vertices(G2); 

G. edges  :=  edges(G\)  U  edges(G2)\ 
return  G\ 
end  graphjunion; 


Figure  5.12:  Algorithm  graphjunion 

complexity  v>f  graphjunion  is  the  sum  of  the  complexities  of  the  two  union  operations,  or 
0(e  +  n),  where  e  is  the  number  of  edges  in  the  largest  of  Gl  and  G2,  and  n  is  the  number 
of  vertices  in  the  largest  of  Gl  and  G2. 

The  correctness  and  complexity  of  graph-merge  depend  solely  on  the  correctness 
and  complexity  of  graphjunion ,  which  have  previously  been  established.  Thus,  graphjmerge 
is  a  correct  algorithm  with  worst-case  time  complexity  of  0(e  +  n),  where  e  and  n  are  the 
number  of  edges  and  vertices  in  the  largest  input  graph. 

Once  the  graphs  have  been  change-merged,  the  remainder  of  the  implementation 
parts  must  be  change-merged.  The  stream  declarations  and  the  timer  declarations  are 
change-merged  using  the  functions  merge-streams  and  merge-timers,  shown  in  Figures 
5.13  and  5.14,  respectively.  Then  the  control  constraints  are  change-merged  using  functions 
appropriate  to  their  map  type.  These  algorithms  are  shown  in  Figures  5.15  through  5.26. 


2.  Change-Merging  the  Stream  and  Timer  Declarations 

The  stream  and  timer  declaration  parts  are  modeled  as  sets,  so  change-merging 
them  is  done  using  common  set  operations.  In  mergejstr earns,  the  two  for  loops  construct 
the  three  pieces  of  the  change-merging  equation  for  sets,  (A— Base),  (AflB),  and  (B— Base). 
The  correctness  and  complexity  of  mergejrtreams  are  identical  to  those  of  mergestates.  In 
mergeJimers ,  the  three  pieces  of  the  change-merging  equation  are  constructed  separately 
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tad  combined  to  provide  the  zeeuh.  The  correctness  end  complexity  of  this  algorithm  is 
identical  to  that  e {  merge.id.set*. 


Algorithm  mergc^atr  tarns  {BASE,  A,  B :  typejieclaration )  return  typcjiedaratian 
MERGE :  typejieclaration ; 
begin 

MERGE  empty Jypejiedaration ; 

for  every  stream  s  in  A  loop 

if  s  is  not  in  BASE  and  s  is  not  in  B  then 
add  s  to  MERGE ; 
end  if; 

if  s  is  in  B  then 
add  to  MERGE ; 
end  if; 
end  loop; 

for  every  stream  a  in  B  loop 

if  *  is  not  in  BASE  and  s  is  not  in  A  then 
add  to  MERGE ; 
end  if; 
end  loop; 
return  MERGE ; 
end  mergcjrtrcams ; 


Figure  5.13:  Algorithm  mergejstreams 


Algorithm  mergeJimers(BASE ,  A,  B :  idjset)  return  idjset 
begin 

Calculate  A  —  BASE. 

Calculate  B  —  BASE. 

Calculate  Af\B. 

Return  (A  -  BASE)\J(AnB)\J(B  -  BASE). 
end  mergeJimers; 


Figure  5.14:  Algorithm  mergeJimers 


3.  Change-Merging  the  Control  Constraints 


Change-Merging  the  Control  Constraints  is  accomplished  by  a  series  of  algorithms 
that  implement  the  models  defined  in  Chapter  III,  Section  D.  Their  correctness  is  established 
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by  their  conformance  to  the  mathematical  models.  Each  one  of  these  algorithms  has  worst- 
case  time  complexity  of  0(n),  except  mergeJriggerjnaps  and  merge  Jimerjopjnaps,  where 
n  is  the  number  of  vertices  in  the  largest  input  prototype.  mergeJriggerjnaps  has  worst- 
case  time  complexity  of  0(ns 3),  where  n  is  the  number  of  vertices  in  the  largest  input 
prototype  and  s  is  the  largest  number  of  streams  read  by  an  operator  in  the  prototype. 
mergeJimerjops  has  worst-case  time  complexity  of  0(nt3),  where  n  is  the  number  of  vertices 
in  the  largest  input  prototype  and  t  is  the  largest  number  of  timer  operations  in  the  prototype. 
Since  these  algorithms  all  execute  independently,  the  worst-case  time  complexity  for  the 
entire  control  constraints  section  is  0(rts 3  +  nt3). 


Algorithm  mergeJriggerjnaps(VERTS :  idjet;  BASE,  A,  B  :  trigger  jnap) 
return  trigger  jnap 
MERGE :  trigger  jmap; 
opJd :  psdtJd ; 

base-trig,  a-trig,  b-trig,  mergeJtrig  :  trigger : 
begin 

for  every  opSd  in  VERTS  loop 
retrieve  baseJtrig  from  BASE ; 
retrieve  aJrig  from  A; 
retrieve  bJrig  from  B; 

merge Jrig  :=  merge Jriggers(basejtrig,  aJLrig,  bJrig); 
bind  mergeJtrig  to  opJd  in  MERGE ; 
end  loop; 
return  MERGE', 
end  mergeJriggerjnaps; 


Figure  5.15:  Algorithm  mergeJriggerjnaps 


There  is  also  an  informal  description  of  the  implementation  part  that  must  be 
change-merged.  The  implementation  descriptions  are  change-merged  using  the  mergeJext 
function  shown  in  Figure  5.6. 
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A,  B :  trigger)  return  trigger  * 

streams :  id^et; 

begin 

if  BASE  *  A  then 
if  BASE  s  B  then 

MERGE.tt :«  BASE.tt 

MERGE. streams  :=  merge.i<Lsets(B, AS E. streams,  A.streams,B. streams); 
return  MERGE ; 
dee  return  B; 
end  if; 

dee  if  BASE  =  B  then 
return  A; 
else  if  A  *  B  then 
return  A; 
return  conflict; 
end  if; 
end  if; 
end  if; 

end  mergeJtriggers ; 


MERGE :  trigger; 


rs(BASE , 


Figure  5.16:  Algorithm  mergeJriggers 


Algorithm  mergejexee.guardjmaps(VERT S :  idjset ;  BASE ,  A,  B :  cxec-guardLmap ) 
return  execjuardjnap 
MERGE :  excc-guardLmapr, 
opjd :  psdlJd ; 

basejtg ,  ojeg,  6_e^,  mergejeg :  expression : 
begin 

for  every  opJd  in  VERTS  loop 
retrieve  basejtg  from  BASE ; 
retrieve  ojep  from  A; 
retrieve  ftueg  from  B; 

mergejeg  :*  meTge.expressians{base.eg,  a.cg ,  6_ey); 
bind  mergejeg  to  opJd  in  MERGE; 
end  loop; 
return  MERGE; 
end  mcrgejexcc-guardjmaps; 


Figure  5.17:  Algorithm  mcrge.exec-guar<Lmaps 
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Algorithm  mergejexpressions(BASE,  A,  B :  expression)  return  expression; 

begin 

if  tqual(BASEy  A)  then 

if  equal(BASE ,  B)  then  return  BASE  else  return  B\  end  if; 
else  if  equal(BASE ,  B )  then  return  A\ 
else  if  equal(At  B)  then  return  A ; 

return  conflict; 
end  if; 
end  if; 
end  if; 

end  merge jexpressions; 


Figure  5.18:  Algorithm  mergejexpressions 


Algorithm  mergejmtput.guard.maps ( V ERTS  :  idjtet;  BASE ,  A,  B  :  out. guar  djnap)  re¬ 
turn  out-gvardjmap 
MERGE :  outjjuardjmap; 
opJd :  psdlJd ; 

base  jog,  cuog ,  b.og,  merge  jog  :  expression: 
begin 

for  every  opJd  in  VERTS  loop 
retrieve  basejog  from  BASE ; 
retrieve  ajog  from  A\ 
retrieve  bjog  from  B; 

merge  jog  :=  merge  jexpr  essions{base.og ,  a.og ,  b.og); 
bind  mergejog  to  opSd  in  MERGE ; 
end  loop; 
return  MERGE ; 
end  merge  jmtputjfuardjmaps ; 


Figure  5.19:  Algorithm  merge.output.guard.maps 
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Algorithm  mergejsxcepJriggerjnaps(VERTS :  id-set;  BASE,  A,  B :  excepJriggerjnap) 
return  excepJriggerjnap 
MERGE :  excepJriggerjnap-, 
opjd :  psdlJd; 

hasejet,ajet ,  Lei , mergejet :  expression: 

begin 

for  every  opjd  in  VERTS  loop 
retrieve  bascjct  from  BASE ; 
retrieve  ajtt  from  A ; 
retrieve  Let  from  B; 

mergtJti  :=  mergcjtxpressions{basc.ct,  a .et.  Let); 
bind  mergejct  to  opjd  in  MERGE ; 
end  loop; 
return  MERGE ; 
end  mergejexcepJriggerjnaps] 


Figure  5.20:  Algorithm  mergejexcepJriggerjnaps 


Algorithm  mergeJimcrjopjnaps(V ERTS  :  id  jet]  BASE,  A,  B  :  timer jvpjmap)  return 
timer jopjnap 

MERGE :  excepJriggerjnap] 
opjd :  psdlSd] 

base  jet,  aset,  Lset,  merge. set :  expression: 
begin 

for  every  opjd  in  VERTS  loop 
retrieve  basejset  from  BASE ; 
retrieve  auset  from  A ; 
retrieve  bset  from  B] 

mergejset  :=  mergeJimcrjopjset(base^set,  asct,  Lset); 
bind  mergejset  to  opjd  in  MERGE ; 
end  loop; 
return  MERGE ; 
end  mergeJimcrjopjmaps] 


Figure  5.21:  Algorithm  mergeJimcrjopjmaps 


103 


Algorithm  mergeJimer.op^ets(BASE ,  A,  B :  timer  jopjset)  return  timer. opjset 
MERGE :  timerjopjtet ; 
tjop :  timer jop] 
begin 

for  every  tjop  in  BASE  loop 
if  member(tjop ,  A)  then 
if  member(tjop,  B)  then 
add{tjyp,  MERGE)] 
end  if; 
end  if; 

for  every  tjop  in  A  loop 

if  notmember{U)p ,  MERGE)  then 
if  mcmbcr(tjop,  B)  then 
add(tjop,  MERGE)] 
end  if; 
end  if; 

for  every  turp  in  B  loop 

if  notmember(tjop1  MERGE)  then 
if  member(t_op,  A)  then 
add{tjop,  MERGE)] 
end  if; 
end  if; 

end  loop; 

return  MERGE] 
end  mergeJimerjopjsets] 


Figure  5.22:  Algorithm  merge-timer jrp^ets 
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Algorithm  mergejperiod{V EFTS  :  id-act;  BASE ,  A,  B :  timmp_map)  return  timing-map 
MERGE :  timing-map; 
opjid :  psdlJd; 

basejoal,  a-val,  Lval,  mcrgc-val :  millisec  :=  0; 

begin 

far  every  <jp_id  in  VERTS  loop 
retrieve  basc-val  from  BASE ; 
retrieve  a_ua/  from  A; 
retrieve  Leal  from  £?; 

mergejoal  :=  merge  Aiming  jdata{base.val ,  a.val ,  Lval); 
bind  mergejoal  to  opJd  in  MERGE ; 
end  loop; 
return  MERGE ; 
end  merge-period; 


Figure  5.23:  Algorithm  mergejperiod 


Algorithm  mergc-f  wjor  jmrt(V ERT S :  id-aet;  BASE,  A,  B :  timing-map) 
return  timingjmap 
MERGE :  timing-map; 
opJd :  psdijd ; 

basejoal ,  a-val ,  Lval ,  mergc-val :  millisec 0: 
begin 

for  every  opJd  in  VERTS  loop 
retrieve  basejoal  from  BASE; 
retrieve  ajoal  from  A; 
retrieve  Lval  from  B; 

mergejoal  :=  mergejmet(base-val ,  a-val,  Lval); 
bind  mergejoal  to  opJd  in  MERGE; 
end  loop; 
return  MERGE; 
end  merge-fwjorjnrt; 


Figure  5.24:  Algorithm  merge-fwjorjnrt 
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Algorithm  mergtjmin.calljper(VERTS  :  id^set;  BASE,  A,  B  :  timing jnap) 
return  timing  jnap 
MERGE :  timing  jnap; 
opJd :  psdlJd ; 

basc-val ,  o_ val,  buval,  merge^val :  millisec  :=  0: 
begin 

for  every  opJd  in  VERTS  loop 
retrieve  basejval  from  BASE', 
retrieve  cuual  from  A; 
retrieve  b.val  from  B; 

mcrgtjual  :=  mtrgtjmcp{ba3t-val,  a.val ,  Lval); 
bind  mtrgtjoal  to  opJd  in  MERGE; 
end  loop; 
return  MERGE; 
end  merge jminjcalljter; 


Figure  5.25:  Algorithm  merge-min.callj>er 

4.  Analysis  of  Implementation  Change-Merge 

Change-merging  the  implementation  of  the  top  level  component  requires  four  main 
operations;  change-merging  the  graphs,  change-merging  the  stream  declarations,  change¬ 
merging  the  timer  declarations,  and  change-merging  the  control  constraints. 

Change-merging  the  graphs  requires  that  each  graph  be  converted  to  a  PDG  using 
buildUPDG  which  requires  0{tn a)  time,  where  n  is  the  number  of  vertices  in  the  graph  and 
t  is  the  number  of  timers  declared  in  the  implementation. 

After  the  prototype  dependency  graphs  are  constructed,  the  affected  parts  of  each 
modification  are  constructed  using  af  fedetLpart  which  has  worst-case  time  complexity 
0(e*),  where  e  is  the  number  of  edges.  Then  the  preserved  part  is  constructed,  and  it 
has  worst-case  time  complexity  0(e*). 
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Algorithm  mergejncp(BASE,A,B :  millisec)  return  millisec 
AJ)1FFJ3ASE,  B-DIFFJBASE,  AJNTJ3 :  millisec ; 

begin 

if  A  >  B  then 
AJNT.B  :=  B; 
else  AJNTJB  :=  A; 
end  if; 

if  BASE  >  A  then 
AJDIFFJBASE  :=  T; 
else  A-DIFFJBASE  :=  A; 
end  if; 

if  BASE  >  B  then 
BJ)IFF-BASE  :=  T; 
else  BJD1FFJ3ASE  :=  B; 
end  if; 

if  A-DIFF.BASE  >  AJNT-B  then 

if  AJD1FFJBASE  >  B-DIFF-BASE  then 
return  A-DIFFJ3ASE\ 
else  return  B_B7 FF-BASE; 
end  if; 

else  if  AJNT.B  >  B-DIFFJ3ASE  then 
return  AJNT-B ; 
else  return  B-DIFFJ3ASE\ 
end  if; 
end  if; 

end  mcrgcmcp; 


Figure  5.26:  Algorithm  mergejncp. 


After  ell  three  of  the  pieces  required  for  change-merging  the  graphs  have  been  built, 
then  they  must  be  change-merged  using  graphjmergt ,  which  contains  two  successive  calls 
to  graphjunion ,  which  we  already  know  requires  worst-case  0(n  +  e)  time.  Therefore,  the 
worst-case  time  complexity  of  change-merging  three  graphs  is: 

0(tn*)  +  0(t 2)  +  0(e3)  +  C(e7)  +  0(n  +  e)  =  0(tn 2  +  e2) 

The  edges  in  the  graph  almost  always  outnumber  the  vertices,  so  we  call  this  0(e7). 

The  correctness  of  the  Implementation  Change-Merge  is  established  by  the  cor¬ 
rectness  of  the  individual  parts.  The  complexity  of  the  Implementation  Change-Merge  is 
dominated  by  the  complexity  of  the  change-merging  of  the  graphs,  so  the  worst-case  time 
complexity  of  the  Implementation  Change- Merge  is  0(e2). 

D.  CREATING  THE  CHANGE-MERGED  PROGRAM 

The  last  algorithm  used  in  this  change-merging  tool  is  buildLprototype,  shown  in  Figure 
5.27.  This  algorithm  takes  the  change-merged  graph  and  removes  the  artificial  timer  edges 
and  external  vertex.  It  then  sets  the  change-merged  graph  in  the  change-merged  prototype. 

Algorithm  buil<Lprototypc(P  :  in  out  psdljcamponent ;  G :  prototypejdcpendcnqj .graph) 

A :  psdlujraph ; 

begin 

assign  G  to  A] 
remove  external  vertex; 
remove  timer  dependency  edges; 
setujraph(A ,  P); 
end  buil<Lprototypc ; 


Figure  5.27:  Algorithm  buil<Lprototype 

The  timer  dependency  edges  are  removed  by  iterating  through  the  edges  of  the  graph 
and  removing  the  appropriate  edges.  This  requires  iteration  over  the  edges  of  the  change- 
merged  graph,  making  the  worst-case  time  complexity  of  this  algorithm  C(e). 

♦ 
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E.  ANALYSIS  OF  THE  CHANGE-MERGING  ALGORITHM 

.« 

The  correctness  of  the  algorithm  ckangejnerge  is  established  by  the  correctness  of 
the  individual  parts.  Since  these  individual  algorithms  are  executed  independently  of  one 
another,  there  are  no  dependencies  between  them,  other  than  those  already  discussed.  The 
complexity  of  this  algorithm  is  calculated  by  adding  the  complexities  of  the  individual  parts. 
It  is  easy  to  see  that  the  complexity  is  dominated  by  change-merging  the  graphs  in  the 
implementation  part,  which  requires  0(c?)  time,  where  e  is  the  number  of  edges  in  the 
largest  graph.  Therefore,  the  worst-case  time  complexity  of  the  entire  algorithm  is  0(e7). 
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VI.  CAPS  MERGE  TOOL 


In  this  chapter  we  describe  an  implementation  for  a  change-merging  tool  resulting  from 
this  effort.  The  tool  has  been  almost  fully  implemented  and  can  easily  be  integrated  into  the 
CAPS  Prototyping  Environment.  It  is  invoked  through  the  Manager’s  Interface  and  provides 
a  substantially  beneficial  tool  for  effective  management  of  large  software  prototypes.  Section 
A  of  this  chapter  describes  the  requirements  for  the  tool.  Section  B  provides  the  instructions 
for  using  the  tool.  Section  C  describes  the  testing  performed  on  the  tool. 

A.  REQUIREMENTS 

The  requirements  for  this  tool  are  divided  into  three  parts;  interface,  functionality  and 
conflict  reporting.  Each  of  these  parts  are  discussed  separately  in  the  subsections  that  follow: 

1.  Interface  Requirements 

a.'  Interface  must  be  consistent  with  other  CAPS  interfaces .  CAPs  uses  a  menu- 
driven  interface  at  the  top  level  and  windows  with  selection  lists  and  pushbuttons  at  lower 
levels.  To  be  consistent,  a  pushbutton  type  interface  was  required  for  the  change-merge  tool 
as  well. 


b.  User  must  be  able  to  choose  any  prototype  currently  in  the  working  directory, : 
The  interface  should  provide  a  list  of  the  prototypes  currently  in  the  user’s  working  directory, 
and  the  capability  for  the  user  to  select  one  of  these  prototypes. 

c.  User  must  be  able  to  select  different  versions  and  assign  them  to  the  different 
merge  parameters  by  pushbutton :  After  the  prototype  has  been  selected,  the  interface  should 


pnmdi  a  lift  of  the  current  vuwsi  of  the  prototype.  The  user  should  then  be  able  to  select 
each  version  fay  clicking  with  the  mouse,  and  assign  the  selected  version  to  one  of  the  merge 
parameters,  base,  versiorua  or  versionJb,  by  pushing  an  assign  button. 

d.  User  should  be  satisfied  that  the  selection  made  has  been  assigned  to  the  correct 
parameter.  The  interface  should  provide  visual  reinforcement  that  the  selection  made  has 
been  assigned  to  the  correct  parameter  by  showing  the  selected  version  in  a  window  labeled 
with  the  parameter  name. 

e.  User  should  be  able  to  initiate  the  merge  tool  by  pushing  a  button:  The  interface 
should  provide  a  button  labeled  “merge”  which,  when  pushed,  will  call  the  merge  tool  for 
the  parameters  given. 

f.  User  should  be  notified  when  merge  is  complete:  The  interface  should  provide 
a  pop-up  window  that  alerts  the  user  that  the  merge  is  complete.  The  result  of  the  merge 
should  be  printed  in  a  window  labeled  “result”. 

g.  User  should  be  notified  if  a  conflict  occurs:  The  interface  should  provide  &  pop-up 
window  that  alerts  the  user  that  a  conflict  has  occurred  during  the  merge. 

h.  User  should  be  able  to  commit  the  result  to  the  design  database  directly  from  the 
merge  interface:  A  pushbutton  should  be  provided  that  allows  the  manager  using  the  tool 
to  commit  the  result  of  the  merge  to  the  database,  even  if  conflicts  have  occurred. 

2.  Functionality  Requirements 

a.  Tool  must  be  able  to  retrieve  the  three  versions  of  the  prototype  when  provided 
only  the  paths  to  their  locations:  The  interface  will  provide  the  full  directory  names  for  each 
of  the  input  versions  as  input  to  the  tool.  The  tool  must  be  able  to  combine  all  of  the  PSDL 
source  files  in  each  of  the  version  directories  into  one  single  file  and  call  the  PSDL  parser  to 
convert  the  text  version  of  the  prototype  into  an  ADT  representation  of  the  prototype. 
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b.  Tool  must  call  the  PSDL  expander  to  provide  fully  expanded  PSDL  programs 
os  input  to  the  change-merge  procedure:  The  PSDL  expander  is  a  tool  which  takes  a  multi- 
leveled  prototype  and  converts  it  into  a  fiat  prototype  with  only  one  composite  component. 

c.  Tool  must  change-merge  the  three  versions  of  the  prototype  according  to  the 
models  provided  by  this  dissertation :  The  change-merge  tool  must  be  able  to  retrieve  the 
composite  component  of  each  version,  and  perform  the  change-merge  operation  using  these 
three  components  as  input.  It  then  must  provide  a  new  composite  component  for  the  merged 
prototype.  The  atomic  components  will  then  be  added  to  the  merged  prototype  according 
to  which  version  supplied  those  components  to  the  merged  implementation  graph. 

d.  Tool  must  split  the  final  version  of  the  prototype  into  separate  files  for  each  of 
the  component  implementations  and  specifications:  The  tool  must  be  able  to  take  the  merged 
prototype  and  output  it  into  separate  files  in  the  result  directory.  Each  file  should  contain 
either  the  specification  part  or  implementation  part  of  one  component.  If  the  component 
is  the  composite  component,  then  the  name  of  the  file  will  be  “prototype_namc.imp.psdr 
or  ttprotoiype.name.spec.psdl”,  depending  on  whether  it  contains  the  implementation  or 
specification  part  of  the  component,  and  where  “prototype-name”  is  the  name  of  the  com¬ 
posite  component.  If  the  component  is  an  atomic  component,  then  the  name  of  the  file 
will  be  “prototype.  name,  component,  namel  .imp . psdl”  if  it  contains  an  implementation  or 
“prototype. name. component. name.spec.psdl”  if  it  contains  a  specification,  where  “compo¬ 
nent-name11  is  the  name  of  the  atomic  component. 

3.  Conflict  Reporting  Requirements 

a.  Tool  must  report  to  the  user  w here  in  the  merged  component  a  conflict  has 
occurred:  In  each  piece  of  the  change-merged  program  where  a  conflict  has  occurred,  the 
tool  must  place  a  flag  indicating  to  the  designer  where  the  conflict  occurred.  This  will 
prevent  the  user  from  having  to  search  for  the  conflict  in  order  to  resolve  it. 
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b.  9W  most  provide  at  least  a  partially  change-merped  propram  in  the  case  of 
iff  eamfiktsc  The  tool  will  provide  the  most  change-merged  program  possible  whenever  a 
conflict  has  occurred.  Conflicts  in  one  part  of  the  program  should  not  affect  other  parts  of 
the  program  which  are  not  dependent  on  the  part  with  the  conflict. 


B.  USING  CAPS  MERGE  TOOL 

To  invoke  the  CAPS  merge  tool,  select  the  merge  prototypes  option  from  the  manager's 
interface.  The  CAPS  merge  tool  window  will  be  displayed  as  shown  in  Figure  6.1.  The  list 
of  currently  available  prototypes  will  be  displayed  in  the  prototypes  box  at  the  lower  left  of 
the  window. 


Figure  6.1:  CAPS  Prototype  Merge  Tool  Interface 


1.  Selecting  Prototypes  and  Versions 


To  select  a  prototype,  click  the  left  mouse  button  over  the  name  of  the  prototype 
to  be  selected.  Clicking  twice  on  the  same  prototype  will  deselect  the  prototype.  After 
selecting  a  prototype  name,  a  list  containing  all  of  the  versions  of  the  selected  prototype  will 
appear  in  the  versions  box  at  the  lower  right  of  the  merge  tool  window,  as  shown  in  Figure 
6.2.  To  select  a  version,  click  the  left  mouse  button  on  top  of  one  of  the  versions.  Again, 
double  clicking  on  the  same  version  will  deselect  the  version. 


Figure  6.2:  CAPS  Prototype  Merge  Tool  Interface  with  List  of  Versions 

2.  Performing  the  Merge  Operation 

To  perform  a  merge,  three  versions  must  be  selected  and  assigned  to  the  merge 
parameter  boxes.  To  assign  parameters,  first  select  the  version,  then  click  the  left  mouse 
button  on  the  "assign”  button  next  to  the  parameter  to  be  assigned.  Figure  6.3  shows  the 
window  after  all  three  parameters  have  been  assigned.  Changing  a  parameter  assignment  is 


done  by  selecting  the  correct  version  and  clicking  on  the  “assign”  button  again.  Every  push 
of  the  “assign”  button  reassigns  the  parameter  to  the  selected  version.  To  clear  all  of  \he 
parameter  assignments,  use  the  clear  button  located  on  the  right  center  of  the  window. 


Figure  6.3:  Assignment  of  Parameters 

When  all  of  the  parameters  have  been  assigned,  the  “merge”  button  located  on  the 
right  side  of  the  window  must  be  pushed.  This  will  invoke  the  change-merge  tool.  When  the 
change-merge  tool  has  completed  its  execution,  one  or  two  windows  will  appear  on  the  screen. 
The  “merge  complete”  window,  shown  in  Figure  6.4,  will  always  appear  after  execution  of  the 
tool.  If  a  conflict  was  detected  during  the  change-merge,  the  “conflict  notification”  window, 
as  shown  in  Figure  6.5,  will  also  appear.  The  manager  can  either  choose  to  keep  the  result 
and  manually  resolve  the  conflicts  or  abandon  the  result  and  start  again. 
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Figure  6.4:  Merge  Complete 


Figure  6.5:  Notification  of  Conflict 


3.  Commit  Merge 

Once  the  merge  has  been  completed,  the  manager  has  to  specifically  commit  the 
result  to  the  design  database.  To  commit  the  merged  result,  the  manager  clicks  the  left 
mouse  button  on  the  “commit  merge”  button  on  the  right  side  of  the  CAPS  Merge  Tool 
window.  A  new  version  number  will  be  assigned  to  result  and  it  will  be  added  to  design 
database  as  a  permanent  part  of  the  prototypes  configuration. 

At  this  point,  the  manager  can  choose  to  perform  another  merge  operation  or  exit 
the  tool.  If  another  merge  is  desired  repeat  the  process  described  above  as  many  times  as 
desired.  To  exit  the  CAPS  Merge  Tool,  click  the  left  mouse  button  on  the  “exit”  button  at 
the  bottom  of  the  window,  and  control  will  be  returned  to  the  CAPS  Manager  Interface. 

C.  TESTING 

We  tested  the  change-merging  tool  by  applying  it  to  a  series  of  sample  prototype  projects 
each  testing  a  different  part  of  the  tool.  These  projects  included  real  prototypes  which 
were  developed  by  students  in  the  CAPS  Research  Team  as  well  as  examples  constructed 
specifically  for  this  test.  The  largest  of  these  prototypes  is  the  Command  and  Control  System 
described  in  [Ref.  36] .  The  implementation  for  this  prototype  contains  27  vertices  and  35 
edges  with  a  full  range  of  control  constraints.  Four  modified  versions  of  this  prototype  were 
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prototype  ware  emled,  and  the  change-merge  tool  was  applied  to  different  combinations  of 

.e 

the  fear,  each  testing  a  different  part  of  the  tool. 

Timing  tests  were  conducted  to  provide  a  realistic  assessment  of  the  speed  with  which 
the  tool  would  operate.  During  the  test  it  was  determined  that  the  time  required  to  process 
each  of  the  input  files  (combining  the  multiple  files  into  one,  parsing  the  input  files,  and 
expanding  the  prototype  to  a  flat  graph)  took  a  significant  amount  of  the  time  for  the 
system  to  run.  In  the  case  of  the  Command  and  Control  prototype,  the  system  took  on 
average  six  seconds  to  process  each  file  and  25  seconds  to  change-merge  them.  In  the  case 
of  the  smaller  prototypes,  the  times  were  significantly  less. 

Since  the  current  implementation  is  not  as  efficient  as  an  optimal  one  outlined  by  the 
algorithms  in  Chapter  V,we  can  expect  a  significant  speedup  for  the  optimal  implementation. 

In  each  test  of  the  change-merge  tool,  the  results  were  exactly  as  expected.  The  tool  produced 
conflicts  whenever  expected  and  correct  results  when  they  were  possible. 
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VII.  CONCLUSION 


A.  WHAT  WE  HAVE  ACCOMPLISHED  AND  WHY  IT  IS  IM¬ 
PORTANT 

The  purpose  of  this  research  was  to  provide  a  computer-aided  method  for  combining 
and  integrating  the  contributions  of  different  people  working  on  the  same  prototype.  It  is 
commonly  known  that  one  of  the  most  time  consuming  and  problematic  parts  of  developing 
large  software  systems  is  combining  independently  developed  pieces  of  the  system  and  en¬ 
suring  they  do  not  conflict.  We  developed  a  computer-aided  method  for  merging  changes  to 
a  prototype  which  will  always  produce  a  correct  result  or  report  a  potential  conflict.  Using 
this  method  provides  a  prototype  development  manager  with  the  ability  to  assign  different 
development  tasks  for  the  same  prototype  to  different  members  of  the  development  team 
and  be  assured  that  the  pieces  can  be  integrated  together  after  their  completion  in  a  safe 
manner.  This  method  will  either  produce  a  change-merged  prototype  that  is  correct  with 
respect  to  the  different  updates  or  it  will  notify  the  manager  that  a  conflict  has  occurred. 

We  found  a  solution  to  an  analog  of  this  problem  in  previous  work  done  on  integrating 
different  versions  of  while  programs  at  the  University  of  Wisconsin  [Ref.  28,  42,  29].  The 
main  difference  between  their  method  and  ours  is  that  while  programs  are  very  different 
from  data  flow  programs.  Data  flow  programs  are  inherently  parallel  and  non-deterministic, 
and  the  class  of  enhanced  data  flow  programs  used  in  PSDL  also  include  hard  real-time 
constraints. 

We  proved  our  method  correct  by  observing  that  slices  of  prototypes  which  isolate  a 
portion  of  the  prototype's  behavior  will  always  behave  the  same  in  any  prototype  where 
they  are  well  defined  slices.  Using  the  Slicing  Theorem  in  Chapter  IV,  we  were  able  to  show 
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that  as  long  as  the  slice  of  the  merged  version  of  the  prototype  with  respect  to  the  affected 

.# 

parts  of  each  modification  was  the  same  as  the  same  slice  of  the  modification,  the  changes 
introduced  by  that  modification  were  presaved  by  the  method. 

To  prove  this  theorem,  we  had  to  develop  a  computational  model  of  the  PSDL  language. 
Chapter  IV  provides  a  detailed  development  of  the  model  of  the  language  from  defining 
the  behavior  on  a  single  stream  in  the  prototype  to  constructing  the  behavior  of  the  entire 
prototype  from  the  behaviors  of  the  individual  operators  in  the  prototype.  This  construction 
is  possible  because  we  showed  in  the  Independent  Opaator  Lemma  in  Appendix  B  that  the 
possibility  function  for  an  operator  is  not  determined  by  the  context  in  which  it  is  placed. 
As  long  as  the  opaator  is  given  the  same  input,  it  will  behave  in  precisely  the  same  way  in 
any  prototype 

FYom  the  model,  we  developed  an  algorithm  which  can  perform  the  change-mage  in 
0(e*)  time  and  0(n2)  space,  and  an  implementation  which  provides  a  working  change- 
mage  tool  to  be  used  in  the  Computa-  Aided  Prototyping  System.  The  algorithm  and  tool 
demonstrates  the  feasibility  of  our  method  for  problems  of  practical  size. 

During  the  course  of  this  research,  we  also  proposed  an  improved  method  for  slicing 
and  merging  while  programs  which  provides  a  strictly  more  accurate  method  than  previously 
defined  methods.  No  proof  of  this  method  is  provided  however.  That  will  be  left  to  future 
work. 


B.  WHAT  STILL  NEEDS  TO  BE  DONE 

We  couldn’t  possibly  solve  all  of  the  world’s  problems  in  the  short  amount  of  time  pro¬ 
vided,  so  there  are  still  many  out  there  to  be  tackled.  Some  of  the  problems  that  we  intend 
to  continue  working  on  are  providing  a  method  for  change-merging  different  versions  of  an 
abstract  data  type  written  in  PSDL.  Our  method  will  currently  handle  the  opaator  imple¬ 
mentations  for  ADTs,  but  fails  to  provide  a  method  for  integrating  the  data  representations. 
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Another  area,  which  needs  consideration  is  the  area  of  merging  programs  in  high  level 
programming  languages,  like  Ada.  In  prototyping  large  systems,  it  is  very  important  to  auto¬ 
mate  as  m  iy  of  the  development  tasks  as  possible  to  minimize  the  drain  on  resources  caused 
by  monotonically  decreasing  budgets.  One  of  the  first  tasks  to  be  finished  is  completing  the 
formalization  of  the  conditional  program  merging  we  proposed  in  Chapter  III. 

Another  area  that  warrants  further  study  is  in  further  improving  the  conflict  detection 
methods  used  in  change-merging.  Automatic  conflict  resolution  tools  would  provide  project 
managers  with  an  even  greater  degree  of  confidence  in  the  change-merging  tools. 


120 


% 

APPENDIX  A 

FORMAL  DEFINITIONS 


This  appendix  contains  formal  definitions  of  the  types,  properties,  and  functions  used 
in  our  behavioral  model  of  PSDL. 

1.  TYPE  DEFINITIONS 

a.  data_tuple{t:  type}  = 

tuple{valuc  :  t,  operator :  op  Jd,  write Jime  :  real,  read Jime  :  real} 

b.  trace{t:  type}  =  se^uence{data_tuple{t}} 

c.  stream_behavior{t :  type}  =  set{trace{t}} 

d.  trace.tuple{P :  prototype}  ss  fap/e{trace{type{s}  ::  s  €  E(P)}} 

e.  prototyp e_b ehavior { P :  prototype}  =  set{trace_tuple{P}} 

f.  incrementaLtrace_tuple{t :  writeJLimt]  = 

tup/e{datajtuple{type{s}  SUCH  THAT  8  €  E{P)} 

::  datsutuple.tortfeJtme  =  t} 

2.  INVARIANT  DEFINITIONS 

We  assume  that  the  implementation  of  an  operating  system  where  a  PSDL  prototype 
is  being  executed  will  guarantee  mutual  exclusion  when  two  operators  executing  in  parallel 
wish  to  write  to  the  same  stream  at  the  same  time.  Because  we  assume  this  control  on  write 
access  for  data  streams,  we  can  guarantee  the  following  invariant  is  true  for  all  data  streams 
in  a  PSDL  implementation. 
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a.  monotonic_time(t :  trace) 

ALL  ( i ,  j:  nat  SUCH  THAT  1  <  <  <  j  <  length(t) 

::  t[i].writeJime  <  t\j\.urriteJtime 

—  The  write  times  in  a  trace  are  monotonically  increasing. 

Since  an  operator  writing  to  a  data  stream  had  to  read  from  its  input  streams  before 
it  completes  execution,  we  can  guarantee  that  any  data  tuple  in  a  trace  will  satisfy  the 
following  invariant: 

b.  firing  invariant  ( t :  trace) 

ALL  (*:  nat  SUCH  THAT  1  <  *  <  length(t) 

::  (t[i].readJime  <  t[i].writeJime)  J  (t[i].readJime  =  t[i].writeJime  =  0)) 

—  The  write  time  in  any  data  tuple  is  strictly  greater  than  the  read  time 

—  in  that  data  tuple,  unless  it  is  the  initial  data  tuple. 

If  an  operator  receives  input  from  a  feedback  loop,  then  the  vertex  associated  with  that 
operator  is  on  a  cycle  in  the  PSDL  implementation  graph.  It  is  necessary  to  know  that 
an  operator  is  on  a  cycle  because  this  information  affects  the  possibility  function  of  that 
operator. 

c.  on_a_cycle(o :  op Jd) 

—  o  provides  output  to  a  feedback  loop  which  in  turn  provides  input  to  o. 


3.  FUNCTION  DEFINITIONS  AND  PROPERTIES 
a.  Merging  Traces 


In  PSDL,  it  is  possible  for  more  than  one  operator  to  write  into  the  same  stream. 
If  this  is  the  case,  each  of  these  operators  independently  writes  a  sequence  of  data  tuples 
to  that  stream.  These  sequences  merge  to  form  a  single  trace  for  the  stream.  The  function 
merge  specified  below  shows  that  this  combination  of  sequences  is  well-defined.  Propositions 
4  through  8  state  properties  about  the  function  merge  which  are  needed  for  our  discussion 
of  possibility  functions  in  chapter  IV. 
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12  :  trace  SUCH  THAT  ALL  (*,  j:  net ::  tl[t].  write-time  ^  t2[j].writeJime) 
REPLY  (13 :  trace)  < 

WHERE  monotonic_time( £ 3 )  it  firing_invariant(t3)  it 

length(t3)  =  length(tl)  +  length(t2)  -  1  it  tl  [0]  =  12[0]  =  *3(0] 

--  Every  trace  contains  an  initial  data_tuple  with  index  zero. 

ALL  (i:  nat  SUCH  THAT  1  <  i  <  length(t3) 

::  SOME(.;:  nat::  (t3(i]  =  tl[y]  it  1  <  j  <  length(tl)) 

|  (t3[i|  =  12\j]  it  1  <  j  <  length(12)))), 

ALL  (i:  nat  SUCH  THAT  1  <  i  <  length(tl) 

::  SOME(jf:  nat::  <3{j]  =  tl[i]  it  1  <  j  <  length(<3))), 

ALL  (i:  nat  SUCH  THAT  1  <  i  <  length(t2) 

::  SOME(j:  nat::  t3[;]  =  t2[<]  &  1  <  j  <  length(13))) 

Proposition  4  merge  is  well-defined 

merge  is  a  total,  single-valued  function  over  the  specified  domain. 

Proof 

Let  tl  and  i2  be  traces  on  a  stream  SUCH  THAT 

Vi,  j  €  R,tl[i].writeJime  ^  t2\j\.writcJime. 

Suppose  t3  =  merge(t\,t2)  and  i4  =  merge(t\,t2)  SUCH  THAT  t3  /  f4. 

Since  t3  and  t4  are  both  valid  results  of  mcrge(tltt2),  we  conclude  that  they  both 
satisfy  monotonicJime  and  length(tZ)  =  length(t4)  =  length(tl)  +  lcngth(t2)  —  1. 

Since  t3  ^  t4,  3*  €  R  |  *  <  length(tZ)  SUCH  THAT 

f 3 [i]. value  ^  tA[i].value  or  t3[i\.operatcr  ^  t4[i].operator  or 

f3[i].writeJime  ^  t4[i].writeJime  or  13[i].readLiime  -f-  t4[i].readJLime  or 

But,  by  the  definition  of  merge ,  every  element  in  both  t3  and  t4  are  elements 
of  either  tl  or  t2,  which  have  no  common  write.times,  and  since  both  t3  and  14  satisfy 
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monotonicJime,  there  is  only  one  way  to  combine  the  elements  of  tl  and  t2  into  a  single 
trace  that  satisfies  monotonicJime.  Thus  <3  =  t4,  and  we  have  a  contradiction,  merge  is 
well-defined.  □ 

Proposition  5  merge  satisfies  monotonicJime 

If  monoionic Jime(tl)  and  monotonicJimc(t2)  then  monotonic Jime{merge{t\,t2)). 

Proof 

We  assume  that  tl  and  t2  have  no  common  write  times,  and  that  monotonicJime 
is  satisfied  for  both  tl  and  t2.  Let  t3  =  merge{t\,t2).  We  show  t3  satisfies  monotonicJime 
by  induction. 

Basis:  length(tZ)  —  1 

Since  every  trace  has  a  data_tuple  with  index  zero,  then  t3  is  the  trace  with  only 
an  initiaLdata_tuple,  and  monotonicJime  is  satisfied. 

Induction  Step:  Assume  that  t3  |  k  satisfies  monotonicJime.  Since  tl  and  t2 
satisfy  monotonicJime,  and  they  do  not  contain  dataJtuples  with  the  same  write  times,  we 
know  that  no  matter  which  of  tl  and  t2  the  k  +  1st  element  of  t3  comes  from,  its  write 
time  will  be  greater  than  tin*.  So,  we  can  conclude  that  the  k  +  1  element  of  t3,  when 
added  will  have  writeJime  greater  than  t3[Jb].  Since  f3  |  k  satisfies  monotonicJime ,  and 
t3[fc  +  l\.writeJime  >  tZ[k].writeJime,  we  conclude  that  monotonic Jimc{tZ)  is  satisfied. 
□ 
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0  MMTfe  wtirfM  firing Jnvariant 


If  firing  Jnvariant  it  satisfied  for  both  <1  and  t2  then  firing  invariant  is  satisfied 
formerga(tltt2). 

Proof 

We  assume  that  <1  and  t2  have  no  common  write  times,  and  that  firing  invariant 
is  satisfied  for  both  <1  and  t2.  Let  <3  =  merge(t\,t2).  We  show  firing Jnvariant(tZ)  by 
induction. 

Basis:  length(tZ)  =  1 

e  every  trace  has  a  data_tuple  with  index  zero,  then  <3  is  the  trace  with 
only  an  initial  data  tuple,  and  too  *  tr0  =  0  by  the  definition  of  initial  data  tuples.  So 
firing  Jnvariant(t2)  is  satisfied. 

Induction  Step:  Assume  that  <3  |  k  satisfies  firing  invariant.  Since  tl  and  t2 
satisfy  firing  Jnvariant  and  each  element  of  <3  is  also  an  element  of  tl  or  t2,  we  know  that 
no  matter  which  of  tl  and  t2  the  k  +  1st  element  of  t3  comes  from,  tto*+1  >  tr*+i.  We  can 
conclude  therefore  that  firing  Jnvariant(t3)  is  satisfied.  □ 

Proposition  7  merge  is  commutative. 

merge(tl,t2)  =  merge{t2,t\) 

Ecfi&f 

We  assume  that  tl  and  t2  have  no  common  write-times.  We  further  assume  that 
since  tl  and  t2  are  traces,  they  both  satisfy  the  trace  invariants  monotonicJime  and  fir- 
ingJnvarianL 

We  show  that  the  merge  function  applied  to  1 1  and  t2  satisfies  these  conditions  and 
the  length  of  the  result  is  exactly  the  same  regardless  of  the  order  of  the  parameters. 


Let  <3  =  mergc(t l,t2). 

Then  length(t3)  =  length(merge(t\,t2 ))  =  length(tl)  4-  length(t2)  —  1. 

But,  since  +  is  commutative,  then 

lengtk(tl)  +  length(t2)  —  1  =  length(t2)  +  length(tl)  —  1  =  length(merge(t2,tl)). 

We  know  by  Proposition  5  that  monotonicJime  is  satisfied  for  both  merge(t\,t2) 
and  mcrgc(t2,tl).  We  know  by  Proposition  6  that  firing  Jnvariant  is  satisfied  for  both 
merge(tl,t2)  and  merge(t2,tl).  Therefore  merge  is  commutative.  □ 

Proposition  8  merge  is  associative. 

If  tl,  t2  and  1 3  each  satisfy  monotonicJime  and  firing  Jnvariant ,  and  they  have 
no  common  times,  then  merge(tl,merge(t2,  f3))  =  merge{merge(t\,t2),tZ). 

Proof 

We  asstime  that  il,  t2  and  <3  have  no  common  write_times.  We  further  assume 
that  since  tl,  t2  and  <3  are  traces,  they  all  satisfy  the  conditions  monotonicJime  and 
firing  Jnvariant. 

Let  <4  =  merge[t\,  merge(t2,  t3)). 

Then  length(t4)  s=  Iength(merge(tl,merge(t2,t3)))  = 
length{t\)  +  length(merge(t2,  <3))  —  1  = 
length(tl)  +  ( length(t2 )  +  lcngth{t3)  —  1)  —  1  = 
length(tl)  +  length(t2)  +  length(t3)  —  1  -  1  as 
(length(t\)  +  length(t2)  —  1)  +  length(t3)  —  1  = 
lcngth(merge(t\,t2))  +  length(tZ)  —  1  = 
lcngth(mcrgc(merge(tl,t2),  t3)). 

So  the  lengths  of  merye(tl,mer^e(f2,t3))  and  merge(merge(tl,t2),tZ)  are  the 
same.  We  know  by  Proposition  5  that  monotonicJime  is  satisfied  for  both  mcrge(t2,  t3)  and 
merge[t l,t2).  Thus  using  the  same  logic,  we  can  conclude  that  monotonicJime  is  satisfied 
for  merge(t\,  merge(t2,  t3))  and  for  merge(merge(tl,t2),t3).  We  know  by  Proposition  6 
that  firing  Jnvariant  is  satisfied  for  both  merge(t2,tZ)  and  merge(tl,t2).  Thus  using  the 
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MOM  kgk,  W  cm I  «mMi  that  firing  Jnverutni  la  satisfied  lor  merye(tl,mer£e(t2,<3)) 
and  fee  M*rg$(mcrgc(tlt  *2), <3).  Therefore  merge  is  associative.  □ 

b.  Other  Functions 


This  section  contains  definitions  for  other  functions  used  to  construct  the  possibility 
functions  for  prototypes. 


(1)  ® 


The  “ffi”  function  extends  trace-tuples  by  appending  incrementaLtr&ce-tuples 
to  them.  It  takes  as  input  a  trace-tuple  T  and  an  incrementaLtrace_tuple_aet  S.  The  output 
of  the  function  is  a  set  of  trace-tuples  where  the  prefix  of  each  element  in  the  set  is  T,  and 
the  remainder  of  each  element  is  an  element  of  5. 

trace-tuple,  5:  incrementaLtrace_tuple_set) 

REPLY  (D:  trace.tuple.set) 

ALL  (tt:  trace-tuple  SUCH  THAT  tt  €  D 

::  SOME(d:  incremental-  trace- tuple  SUCH  THAT  d  €  S’ 

::  tt  =  append(T,  d))) 


(2)  A 


The  A  function  is  used  to  select  incrementaLtraceLtuples  which  have  a  partic¬ 
ular  write-time. 

A(t:  time,  51:  incrementaLtrace_tuple_set) 

REPLY  52:  incrementaLtrace-tupleLset 

ALL  (D:  incrementaLtrace_tuple  SUCH  THAT  D  €  52 
::  ALL(d:  datajtuple  SUCH  THAT  deD 
::  d.writeJimt  =  t )) 


The  p  function  provides  the  earliest  possible  time  that  an  operator  can  read 
its  input  streams  based  on  its  output  history.  If  the  operator  is  on  a  cycle  in  the  graph, 
then  it  must  complete  every  firing  to  include  writing  its  output  streams  before  it  can  read 
its  input  streams.  If  it  is  not  on  a  cycle,  then  it  does  not  have  to  wait  for  a  previous  firing 
to  be  complete  before  it  can  read  its  input  streams  again. 

p(T:  trace-tuple,  o :  op  Jd)  REPLY  t:  time 
SOME(a:  stream-set  SUCH  THAT  s  C  0(o) 

::  ALL(r:  trace  SUCH  THAT  r  €  T. 

::  WHEN  on-a_cyde(o)  t  >  T[length(r)  —  \].writeJLimt 
::  OTHERWISE  t  >  T[length(r)  —  \].readJime 

(4)  fill 

The  fill  function  takes  as  input  an  incrementaLtrace_tuple_set  from  the  output 
streams  of  an  operator  and  for  each  incrementaLtrace^tuple  in  the  set,  it  creates  an  empty 
datajtuple  for  all  other  streams  in  the  prototype. 
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APPENDIX  B 


EFFECTS  OF  CONTROL  CONSTRAINTS  ON 
POSSIBILITY  FUNCTIONS 


This  appendix  defines  the  effect  of  each  form  of  constraint  contained  in  the  PSDL 
grammar  an  the  possibility  function  of  an  operator.  The  possibility  function  for  an  operator 
o  is  a  function  of  the  form,  ^(I*,  rt),  where  Ic  is  the  input  history  of  the  operator  o,  and  rt 
is  the  last  possible  time  that  o  could  have  read  its  streams  for  the  current  firing.  The  output 
of  the  possibility  function  is  a  set  of  possible  incrementaLtrace_tuples  written  to  the  output 
streams  of  o  by  the  current  firing  of  o.  Examples  of  possibility  functions  can  be  found  in 
Chapter  IV,  Section  A.3,  Examples  5  and  6. 

The  main  result  in  this  appendix  is  Lemma  1,  the  Independent  Operator  Lemma, 
which  states  that  the  possibility  function  of  an  operator  is  not  dependent  on  the  context  in 
which  it  is  placed. 

Lemma  1  Independent  Operator  Lemma 

Given  the  same  input  history  and  an  unlimited  number  of  processors,  an  operator  has 
the  same  possibility  function  regardless  of  whether  it  is  contained  in  a  larger  prototype,  as 
long  as  the  larger  prototype  does  not  introduce  input  to  the  operator  from  a  feedback  loop. 

Ecofifi 

This  proof  is  a  structural  induction  over  all  of  the  different  control  constraints  in  the 
PSDL  grammar.  First,  let  us  look  at  the  possibility  function  for  an  operator  o,  T0.  This 
possibility  function  produces  a  set  of  possible  incremental  trace  tuples  for  every  finite  prefix 
of  input  vectors  written  to  the  operator’s  input  streams. 


Each  of  the  following  sections  discusses  how  each  of  the  control  constraints  available  in 
PSDL  affects  the  possibility  function  for  o. 

1.  Triggers  U  Input  Guards 

The  “Triggered”  control  constraint  defines  the  conditions  which  trigger  the  execution 
of  o.  The  two  options,  "by  all*  and  “by  some”  identify  any  input  streams  listed  after  them 
as  data  flow  streams  or  sampled  streams  respectively,  and  any  time  a  value  is  written  to  one 
of  those  streams,  it  can  only  be  removed  from  the  stream  by  a  firing  of  the  operator  o  for 
data  flow  streams,  and  a  producer  operator  for  sampled  streams.  Another  option  which  may 
appear  in  a  triggering  constraint  is  an  input  guard.  These  appear  as  boolean  expressions 
that,  if  satisfied,  allow  the  operator  o  to  fire. 

a.  “by  all” 

The  “by  all  stnam^sef  trigger  appearing  in  a  control  constraint  limits  the  execution 
of  the  operator  o  to  fire  only  when  there  is  a  new  value  on  each  of  the  streams  in  strtamsct. 
The  effect  of  this  on  Ta  is  that  it  limits  the  read  times  for  which  o  can  produce  a  set  of 
non-empty  incrementaLtrace.tuples.  Since  the  output  of  T0  is  determined  only  by  the  input 
history  of  o,  which  we  have  assumed  to  be  the  same  in  any  context,  this  only  serves  to  limit 
the  possible  output  histories.  These  output  histories  are  the  same  regardless  of  whether  o  is 
contained  in  a  larger  prototype  or  functions  independently. 

b.  “by  some ” 

A  similar  argument  can  be  made  for  the  “by  some  stream^sef  trigger.  The  input 
sequences  processed  by  o  are  limited  to  only  those  sequences  of  vectors  in  which  at  least  one 
of  the  streams  listed  in  streamlet  contains  a  new  value.  The  effect  of  this  limitation  is  the 
same  as  in  the  previous  section. 
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c.  Input  Guards 


Input  guards  in  the  triggering  condition  of  an  operator,  o,  define  which  input  values 
can  trigger  the  execution  of  o.  Their  effect  is  to  limit  the  read  times  at  which  the  operator 
can  fire.  Since  that  effect  only  serves  to  limit  the  execution  of  o,  it  is  the  same  whether  or 
not  the  operator  is  contained  in  a  larger  prototype  or  not. 

2.  Period 

Operators  with  a  period  constraint  are  declared  with  a  time  t.  After  an  initial  delay  of  as 
much  as  i  time,  the  operator  is  given  a  window  of  i  amount  of  time  in  which  to  fire.  As  long 
as  the  operator  fires  early  enough  to  complete  its  execution  before  the  end  of  the  period,  a 
set  of  possible  outputs  will  be  written  to  its  output  streams.  This  set  of  outputs  is  produced 
non-deterministically  because  of  the  flexibility  the  operator  has  in  starting  its  execution. 
This  non-deterministic  start  time  will  change  the  time  that  the  operator  reads  its  input 
streams,  thereby  changing  the  possible  outcome.  Since,  we  are  assuming  that  the  number  of 
processors  is  unlimited,  we  conclude  that  no  matter  whether  the  operator  is  contained  in  a 
larger  prototype  or  not,  all  choices  for  read  times  are  possible,  thus  the  possibility  function 
for  the  operator  will  be  the  same  in  either  case. 

3.  Finish  Within,  Minimum  Calling  Period  &  Maximum  Response 
Time 

Operators  with  a  finish  within,  minimum  calling  period  or  maximum  response  time 
constraint  are  declared  with  a  time,  t.  The  minimum  calling  period  constraint  serves  to 
limit  the  possible  read  times  of  the  operator,  and  the  finish  within  and  maximum  response 
time  constraints  limit  the  possible  write  times  of  the  operator,  however  these  constraints 
are  not  dependent  on  the  context  in  which  the  operator  is  placed  as  long  as  the  number  of 
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processors  is  not  limited.  Therefore,  the  possibility  function  for  the  operator  is  the  same 
whether  it  is  contained  in  a  larger  prototype  or  not. 

4.  Constraint  Options 

Constraint  options  include  output  guards ,  exceptions  and  timer  operations.  Output 
guards  can  affect  the  possibility  function  of  an  operator,  but  these  are  part  of  the  definition 
of  the  operator.  Thus,  the  effect  of  these  output  guards  on  the  possibility  function  for  the 
operator  is  the  same  regardless  of  whether  the  operator  is  contained  in  a  larger  prototype. 
Exception  triggers  contained  in  the  implementation  of  an  operator  can  affect  outputs  on 
streams  of  type  exception,  and  their  triggering  is  affected  only  by  the  inputs  provided  to 
the  operator,  so  the  exception  outputs  resulting  from  possible  inputs  to  the  operator  would 
be  the  same  regardless  of  whether  the  operator  is  contained  in  a  larger  prototype.  Timer 
operations  affect  the  outputs  on  timer  dependency  edges  only.  These  timer  operations  affect 
the  state  of  a  timer  if  some  predicate  evaluated  on  the  inputs  to  the  operator  is  satisfied. 
Since  the  inputs  to  the  operator  are  the  same  when  the  operator  is  contained  in  a  larger 
prototype,  the  resultant  timer  state  change  operations  will  be  the  same  if  the  operator  is 
contained  in  a  larger  prototype. 

Since  the  control  constraints  and  the  output  history  of  an  operator  can  only  depend  on 
the  input  received  from  the  data  streams  and  timer  dependency  edges,  and  we  know  these 
to  be  the  same,  putting  the  operator  in  the  context  of  a  larger  prototype  can  not  affect  its 
possibility  function.  □ 

It  is  important  to  note  that  Lemma  1  applies  equally  to  operators  which  are  components 
of  larger  operators,  or  operators  which  implement  some  operation  in  an  abstract  data  type. 
Prom  our  perspective,  there  is  no  difference. 
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APPENDIX  C 

PROOFS  OF  THEOREMS 


1.  $:  Traces  — ►  FunctionRepresentations  IS  WELL-DEFINED 
AND  A  BDECTION 

THEOREM  2: 

Proof 

1.  Show  ♦  is  single- valued  and  a  total  function.  Let  r  be  a  trace  on  a  stream,  and  let 
and  be  two  functional  representations  for  r  SUCH  THAT  Vi  /  93. 

Since  ¥,  ^,,3a  time  t  €  (0,  oo)  SUCH  THAT  ¥j(<)  ^  ¥3(<). 

But,  then  by  the  definition  of  $-1  3 n  <  mm(length($~1(¥i)),length($~1('I'3))) 

SUCH  THAT 

♦-1(^i)[n].va/ue  /  ♦”1('®r3)[n].va/ue  or 
♦“'(♦jJInj.operotor  ♦"l(#3)[n].operafor  or 
♦~1('i,i)ln].tDr»<eJ*me  ^  ♦”l(^3)[n].writeJime  or 
♦^(VkiJInl.readJime  ^  ♦~1(^3)(n].readJ»me. 

Thus,  ^  ♦"'(♦s),  but  we  know  that  =  $"1(’lr3)  =  r,  and 

we  have  a  contradiction. 

Therefore,  ♦  is  well  defined. 

2.  Show  4  is  onto.  Let 

JO,*,)  —  [±,J.,0] 

•  •  • 

(^IhWi)  *  {*»» 

be  a  mapping  in  ¥. 
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Then  by  definition  of 


M  =  *(((-L,  X,  0, 0],  (xlf  oj ,  <r, ,  tu>,],  •  •  • ,  (x„,  o,,  trn ,  twn],  •  •  •)) 
or  *n+l  =  OO. 

Therefore,  $  is  onto. 

3.  Show  r^s  sss>.  *(r)  ^  ♦(*) 

Let  r  and  s  be  two  traces  on  a  stream,  where  r  ^  s. 

Then  3n  <  max (length(r),  length(s))  SUCH  THAT 
r[n].va/ue  ^  s[n].value  or  r\n].operaior  ^  s[n).oj>trator  or 
r[n].tartfeJ<me  ^  s[n].twtfeJ*me  or  r\n).rtadJimt  ^  s[n].rea<Ltimc. 

If  r[n].tortfeJtme  ^  *[n].t&rifeJtme 

then  3t  <  min(r[n].inr»feJ*me,s[n].tor*teLf*me)  SUCH  THAT 
*(r)(0  *  *(*)(<). 

If  (r[n].read_t*me  ^  s[n].read.ttme  or  r[n].vaiue  ^  s(n], value) 
and  r[n].i0rtteJtme  =  s[n].tnr*feJtme 

then  3 1  *  r[n].ior*feJ*'me  *  8[n).writcJimc  SUCH  THAT 
*(r)(<)  *  *(*)(<). 

Therefore,  ♦(r)  ^  ♦(«),  and  ♦  is  one-to-one. 

By  1,  2  &  3,  ♦  is  a  Bijection.  □ 

2.  SLICING  THEOREM  FOR  PSDL  PROTOTYPES 

THEOREM  3:  Slicing  Theorem 

Let  Sp(X)  be  the  slice  of  a  prototype  P  with  respect  to  a  set  of  streams  X.  Then 
Sp(X)  and  P  have  the  same  prototype  behavior  on  any  subset  of  the  streams  in  SP(X). 


134 


Erfifif 

.t 

Let  Sp(X)  be  an  arbitrary  slice  of  a  prototype  P.  We  show  that  at  any  point  during 
the  execution  of  Sp(X),  both  P  and  Sp(X)  have  the  same  truncated  prototype  behavior 
over  the  data  streams  in  Sp(X).  From  this,  we  conclude  that  the  prototype  behavior  over 
any  subset  of  the  data  streams  in  Sp(X)  is  the  same  in  both  the  slice  and  the  prototype. 

Using  $,  we  view  each  of  the  trace  tuples  in  B^s^*))  |  k  as  a  sequence  of  vectors,  each 
vector  containing  a  data  tuple  from  each  data  stream  in  E(Sp(X))  and  do  an  induction  over 
the  length  of  the  longest  sequence. 

Induction  Hypothesis: 

If  the  length  of  the  longest  sequence  of  vectors  in  B^s^x))  is  no  more  than  k,  then 
B£(Sp(jr»  is  the  same  in  both  P  and  5p(A"). 

Basis:  (Sequence  of  length  one) 

The  semantics  of  PSDL  determine  an  initial  data  tuple  for  each  stream.  The  read 
time  and  write  time  of  this  initial  data  tuple  are  both  0.  If  the  stream  is  declared  as  a 
state  variable,  then  the  initial  data  tuple  contains  a  data  value  specified  by  the  STATE 
declaration,  and  otherwise  it  contains  the  undefined  data  value  X.  The  operator  field  of  the 
data  tuple  contains  either  the  id  of  the  operator  containing  the  state  variable  declaration 
for  the  stream,  if  one  is  declared,  or  X.  Since  the  state  variable  declarations  are  the  same  in 
both  P  and  Sp(X),  the  B  over  all  of  the  streams  in  Sp(X)  is  the  same  in  both,  when  the 
length  of  the  longest  sequence  of  vectors  is  one. 

Induction  Step:  (Bf;(s,(x))  is  a  sequence  of  length  k  +  1) 

Equation  1  shows  us  that  B e(s?(X))  |  (fc+ 1)  is  completely  determined  by  Be^x))  I  k. 
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|  (A-f  1)  = 

U  fr®  U  (W  U  f U  ^  (t./»M(£c/»),^,(7v(.>,*r 

T€B*,,(X»|*  S€*(V(S,(X)))  \o€S  \,(T,o)<tT  \tr<t 

(1) 

Since  B E(sf(X))  I  A  is  the  same  in  the  slice  and  the  entire  prototype  by  the  induction 
hypothesis,  B^s^*))  |  (A  +  1)  must  also  be  the  same  in  the  slice  and  the  entire  prototype. 

Consider  the  main  subexpression  of  the  right  hand  side  of  Equation  1: 

r®  u  (©(  U  (uM<,/a/(«(n#'*(rJW,«r) 

S€r(V(S,(X)))  \*€S  \p(T+)<tr  \tr<t 

This  construction  defines  a  set  of  trace  tuples  of  length  A  +  1  in  terms  of  a  trace  tuple  r 
of  length  A  and  a  set  of  incremental  trace  tuples  of  length  one  that  is  derived  from  T  and 
the  properties  of  the  slice.  This  set  of  trace  tuples  is  a  subset  of  B e(sp(X))  I  (A  +  1).  The 
®  operation  is  a  function,  so,  providing  the  trace  tuple,  T,  and  the  set  of  incremental  trace 
tuples  are  the  same  in  both  P  and  Sp(X),  the  resultant  subset  of  B E(sr(X))  I  (A  +  1)  is  the 
same  in  both  P  and  Sp(X). 

The  set  of  trace  tuples,  B e(s,(X))  I  A  is  the  projected  B  of  P  over  the  streams  in  Sp(X),  so 
any  trace  tuple,  T  €  Be(s,(x»  |  A  is  certainly  the  same  in  both  P  and  Sp(X),  as  Sp(X)  is 
a  subgraph  of  P. 

The  set  of  possible  incremental  trace  tuples,  D,  used  in  the  above  construction  is  constructed 
using  the  following  equation: 

D=  U  (®(  U  fUA(«./i«(E(P),^(TV(.).<r) 

S€P(V(Sr(X)))  \o€S  \p(T*>)<tr  \tr<t 

D  is  constructed  by  looking  at  every  possible  subset  of  the  operators  in  Sp(X),  building  the 
set  of  possible  incremental  trace  tuples  for  the  output  streams  of  that  subset  and  finding  the 
union  over  all  subsets.  Since  the  powerset  of  the  the  set  of  operators  in  Sp(X),  V(V(Sp(X))), 
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k  the  «une  in  both  P  end  Sp(X),  then  the  union  over  ell  of  the  subsets  is  the  seme  in  both 


P  end  Sp(X)  provided  that  the  incremental  trace  tuples  produced  for  each  subset  are  the 
seme  in  both. 

Pick  en  arbitrary  S'  €  V(V(Sp(X))).  We  want  to  construct  the  set  of  possible  incremental 
trace  tuples  over  the  output  streams  of  the  operators  in  S'.  To  do  this,  we  must  look  at 
each  operator,  and  construct  the  set  of  possible  incremental  trace  tuples  over  their  output 
streams.  Then,  we  take  each  of  those  and  combine  them  using  the  0  function.  Since  an 
incremental  trace  tuple  is  simply  a  trace  tuple  of  length  one,  the  function  ©  can  be  overloaded 
to  accomplish  this  task  as  well.  The  operator  0  is  a  commutative  function,  so  as  long  as  the 
incremental  trace  tuples  produced  by  each  operator  are  the  same  in  both  P  and  Sp(X),  their 
combination  using  0  is  the  same  in  both  P  and  Sp(X).  Accordingly,  we  pick  an  arbitrary 
operator,  v.  Constructing  the  set  of  possible  incremental  trace  tuples  for  o  is  accomplished 
using  the  following: 


u 

p(T*)<tr 


(U(A  (tjitl  (E(P),r.(.TlM,tr))fj 


By  Lemma  1,  we  know  that  the  set  of  incremental  trace  tuples  produced  by  o  is  the  same  in 
both  P  and  Sp(X).  Now  since  we  already  knew  that  T  is  the  same  in  both  P  and  Sp(X), 
and  we  know  that  ©  is  a  function,  we  conclude  that  the  resultant  set  of  trace  tuples  is  the 
same  in  both  P  and  Sp(.X'),  for  each  T  €  B£(sf(x))  I  k.  Further,  we  conclude  that  the  union 
over  all  possible  trace  tuples  in  B E(Sp(X))  I  k  is  the  same  in  both  P  and  Sp(X).  Therefore, 
B^(5,(jr))  |  (Jfc  + 1)  is  the  same  in  both  P  and  Sp(X). 

Since  any  finite  prototype  behavior  over  the  set  of  streams  in  the  slice  is  the  same  in  both 
P  and  S/»(X),  we  conclude  that  any  finite  behavior  over  a  subset  of  the  streams  in  the  slice 
is  the  same  in  both  P  and  5/>(X). 

Now,  we  want  to  show  that  any  countably  infinite  prototype  behavior  is  the  same  in 
both  P  and  Sp(X).  Assume  not.  If  any  countably  infinite  prototype  behavior  is  not 
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the  seme  in  both,  then  there  must  be  a  finite  prefix  which  is  not  the  same  in  both  P  and 
Sp(X).  However,  according  to  our  induction  above,  ail  finite  subsequences  of  Be(s,(X))  are 
the  same  in  both,  thus  we  have  a  contradiction.  Therefore,  any  countably  infinite  prototype 
behavior  over  a  subset  of  the  streams  in  Sp(X)  is  the  same  in  both  P  and  Sp(X).  □ 

The  construction  shown  in  Equation  1  defines  the  behavior  of  a  prototype  in  PSDL.  Since 
PSDL  is  non-detenninistic  and  can  be  executed  in  parallel,  it  is  necessary  for  us  to  consider 
all  possible  execution  circumstances.  What  the  construction  really  does  is  lengthen  the 
prototypes  behavior  one  incrementaLtrace_tuple  at  a  time.  This  incrementaLtrace_tuple 
added  to  the  end  of  the  behavior  at  some  time  t  is  the  output  of  every  operator  in  the 
prototype  that  is  writing  to  its  output  streams  at  precisely  time  t.  This  can  be  every 
operator  in  the  prototype  or  only  one  operator  in  the  prototype. 


138 


APPENDIX  D 


PSDL  Grammar 


The  following  is  the  grammar  listing  for  the  Prototyping  System  Description  Language 
(PSDL)  as  of  14  November  1991.  This  version  corresponds  to  the  implementation  of  our 
merging  tool.  Optional  items  are  enclosed  in  ( square  brackets  ].  Items  which  may  appear  zero 
or  more  timw  appear  in  {  braces  }.  Terminal  symbols  appear  in  BOLDFACE.  Groupings 
appear  in  (  parentheses  ). 

♦♦♦a******************************************************************** 


psdl 

=  {component} 

component 

=  datatype 
|  operator 

datatype 

=  type  id  type_spec  typeJmpl 
type_spec 

=  specification  [generic  typejdecl]  [type_decl] 
{operator  id  operator  .spec} 

[functionality]  end 


operator 

=  operator  id  operator  .spec  operator  Jmpl 
operator jspec 

s=  specification  {interface}  [functionality]  end 
interface 

as  attribute  [reqmts-trace] 
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Attribute 

*  generic  typejded 
|  input  typejded 
{  output  typejded 

|  states  type-ded  initially  initiaLexpressionJist 
|  exceptions  idJist 
|  maximum  execution  time  time 

typejded 

ss  idJist :  type _name  {,  idJist :  type_name} 

typename 
SB  id 

|  id  [  typejded  ] 


idJist 

bb  id  {,  id} 

reqmtsjtrace 

bb  required  by  idJist 

functionality 

=  [keywords]  [informaLdesc]  [formaLdesc] 
keywords 

be  keywords  idJist 

informaLdesc 

=  description  {  text  } 

formaLdesc 

be  axioms  {  text  } 

typeimpl 

be  implementation  ada  id  end 

|  implementation  typename  {operator  id  operator  Jmpl}  end 
operatorJmp* 

=  implementation  ada  id  end 
|  implementation  psdUmpl  end 

psdLimpl 

b:  data-flow  .diagram  [streams]  [timers]  [controLconstraints]  [informaLdesc] 

data-flow  -diagram 

=  graph  {vertex}  {edge} 
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-  tine  it  the  maximum  execution  time 


edge 

3=  edge  id  [:  time]  opJd  — »  opJd 
-  time  it  the  latency 

opdd 

=  id  [(  [id-list]  |  [id-list]  )] 

streams 

=  data  stream  type_decl 

timers 

s  timer  idJist 
control-constraints 

=  control  constraints  constraint  {constraint} 

constraint 

=  operator  op  Jd 

[triggered  [trigger]  [if  expression]  [reqmtsLtrace]] 
[period  time  [reqmt&Jtrace]] 

[finish  within  time  [reqmtsJtrace]] 

[minimum  calling  period  time  [reqmtsLtrace]] 
[maximum  response  time  time  [reqmts-trace]] 
{  constraint  .options} 

constraint  joptions 

=  output  idJist  if  expression  [reqmtsLtrace] 

|  exception  id  [if  expression]  [reqmtsLtrace] 

|  timer _op  id  [if  expression]  [reqmtaL  trace] 

trigger 

as  by  all  idJist 
|  by  some  idJist 

timerjop 

as  reset  timer 
|  start  timer 
|  stop  timer 

initiaLexpression-list 

as  initial-expression  ,  initiaLexpression 
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initial-expression 

*  true 
|  false 

|  integer-literal 
j  real-literal 
j  string-literal 
|id 

|  type-name  .  id  [(  initiaLexpression-list  )] 

|  ( initial-expression  ) 

|  initial  -expression  binary _op  initiaLexpression 
|  unary jop  initiaLexpression 

binary jop 

*  and 
|  or 

|  xor 
li 
U 
1  = 
u* 

li* 

I/* 

1  + 

I- 

I* 

I* 

1/ 

|  mod 
|  rem 


unary  _op 

=  not  |  abs  |  -  |  + 


time 

=  integer-literal  unit 

unit 

=  microsec 
|  ms 
|  sec 
|  min 
|  hours 
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■  true 
|  Wee 

j  integer-literal 
|  time  |  reaUiteral 
j  string-literal 

|id 

|  type_name  .  id  [(  expression-list  )] 

|  (  expression ) 

|  initiaLexpression  binary.op  initial-expression 
|  unary  jop  initial-expression 

id 

« letter  {alpha-numeric} 
reaUiteral 

=  integer-literal .  integer-literal 

integerJiteral 

*  digit  {dipt} 

string-literal 

=  "  {char}  » 


char 

*  any  printable  character  except  } 

digit 

=  0  ..  9 

letter 

*  a  ..  s 
|  A..  Z 

I- 

alpha.numberic 
=  letter 
Idigit 


text 

=  {char} 
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APPENDIX  E 

Ada  Implementation  Code 


On  the  following  pages  are  contained  the  implementation  code  for  the  current  version 
of  the  Change-Merge  Tool.  This  tool  used  the  PSDL  Abstract  Data  Type  developed  n  Ada 
by  other  members  of  the  CAPS  Research  Team,  as  well  as  the  PSDL  Expander  developed 
and  implemented  by  Dr.  Berzins.  The  code  for  these  systems  are  not  included  in  this 
dissertation. 

The  code  contained  in  this  appendix  is  broken  up  into  different  files.  Each  section  of 
this  appendix  will  contain  a  different  file.  All  code  was  implemented  in  Ada  and  compiled 
using  the  Sun  Ada  Compiler  Version  1.0. 
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1.  merge.maiiL.pkg 


—  COMPONENT  NAME 

—  OSAGE 


—  INPUT/OUTPUT 

—  AUTHOR 

—  DATE  OF  CREATION 

—  LANGUAGE  USED 

—  COMPILER  USED 

—  PURPOSE 

—  FILES  USED 

—  NOTES 


PACKAGE  MERGE. MAIN.PKG  (  merge.main.pkg.s .a  ) 

Used  to  parlors  all  of  the  housekeeping  and  interface 
between  the  CAPS  interface  and  the  change-merge  system 
developed  by  Dave  Dampier. 

Jim  Brockett 
28  NOVEMBER  1993 
Ada 

Sun  Ada  1.0 

Provides  three  functions  used  by  the  Merge  Interface; 
merge,  find.Base,  and  commit.merge . 

This  is  the  module  to  which  the  TAE  interface  code  for 
the  CAPS  merge  tool  connects.  Calls  are  made  from  the 
merge  interface  to  this  package.  It  is  TBD  whether  or 
not  the  actual  merge  software  is  integrated  into  this 
package  or  put  separately  elsewhere.  Either  way  will 
work.  The  purpose  of  this  packaage  is  integration 
specification. 


MODIFICATIONS 


DATE  :  19  APRIL  1994 

—  AUTHOR  :  Dave  Dampier 

—  PURPOSE  :  Completed  Integration  with  Change.Merge.Pkg. 

—  AFFECTED  MODULES  :  All 


145 


with  unix.prcs ;  us*  unix.prcs ; 

with  unix.dirs;  us*  unix.dirs; 

with  tazt.io;  usa  taxt.io; 

with  a.strings ;  us*  a. strings; 

with  psdl.prograa.pkg;  uso  psdl.prograa.pkg; 

with  psdl.io;  us*  psdl.io; 

with  szpaadsr.pkg;  osa  sxpandsr.pkg; 

with  changs.asrga.pkg;  us*  changs.asrgs.pkg; 

packags  asrgs.aain  is 

procsdurs  asrgs  (BASE. VERSION, 

VERSION. A, 

VERSION.B  :  in  a.string; 

RESULT  :  in  out  a.string; 
CONFLICT  :  in  out  boolaan); 

procsdurs  find.Bass  (VERSION. A, 

VERSION.B  :  in  a.string; 
BASE. VERSION  :  in  out  a.string; 
ERROR  :  in  out  boolaan) ; 

procsdurs  coaait.asrgs  (BASE. VERSION , 

VERSION. A, 

VERSION.B  :  in  a.string; 

RESULT  :  in  out  a.string); 

and  asrgs.aain; 
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pacing*  body  mgcjuis  is 


prototype.patb_orror:  exception; 

procedure  system. call (command  :  in  string)  is 
procedure  system_C( command  : address); 
pragma  INTERFACE (C,  system.C) ; 
pragma  IMTERFACE_KAME( system.C ,  ".system"); 
temp  :  constant  STRING  :*  comm andA ASCII .MOL; 
error:  integer; 

begin 

system.C  (TEMP*  ADDRESS) ; 

end  syst*m.call; 
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—  Local  function  to  extract  tho  nano  of  the  prototype  fron  the 

—  version  string.  Raises  PROTO  TYPE.PATH.ERROR  if  an  a.string  without 

—  the  substring  "/.caps/"  is  received  as  P. 


function  nane.of .prototype (P  :  a.string)  return  a.string  is  „ 

pnaae  :  string (l .  .P.len) ;  —  to  hold  prototype  nano, 

indexl  :  integer  :»  P.len;  —  to  iterate  through  P. 

index2  :  integer  :■  1; 
slash.not. found  :  boolean  :*  true; 

begin 

for  i  in  1.. P.len  loop 
pname(i)  :■  ascii .nul; 
end  loop; 

for  i  in  1..2  loop 

while  slash.not .found  loop 
indexl  :■  indexl  -  1; 
if  indexl  <  1 

then  raise  prototype.path_error; 
end  if; 

if  P.s (indexl)  «  •/• 
then 

slash.not .found  :*  false; 
end  if; 
end  loop; 

slash.not .found  :«  true; 
end  loop; 

indexl  :«  indexl  4  l; 
while  slash.not .found  loop 
if  P.s(indexl)  ■  ’/’ 
then 

slash.not .found  :*  false; 

else 

pname(index2)  :•  P.s(indexl); 
indexl  :■  indexl  4  1; 
index2  :*  index2  4  1; 
end  if; 
end  loop; 

return  truncate (to.a(pnane) ,index2) ; 
end  nane.of .prototype; 
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—  Procedure  aerge  reads  in  three  prototypes  and  change-serges  them, 

—  returning  a  file  name  holding  the  resultant  prototype  froa  the 

—  change-aerge . 


procedure  aerge  (BASE. VERS ION, 


VERSION.A, 
VERSION.B  :  in 

a.  string; 

RESULT  :  in 

out  a. st ring; 

CONFLICT  :  in 

out  boolean)  is 

PROTOTYPE.NAME 

a_string; 

FILE.STRING 

a_  string; 

BASEFILE 

file.type; 

—  Used  to 

hold 

AFILE 

file.type; 

II 

BFILE 

file.type; 

••  II 

MERGEFILE 

file.type; 

..  II 

BASE 

psdl.prograa; 

—  Used  to 

hold 

OPA 

psdl. program; 

—  Used  to 

hold 

OPB 

psdl.prograa; 

—  Used  to 

hold 

MERGE 

psdl.prograa; 

—  Used  to 

hold 

TEMP 

status.code; 

begin 

expanded  file. 

II  II 

•I  II 

II  It 

base  program, 
first  modification, 
second  modification, 
merged  program. 


—  reads  in  Base  prototype  and  puts  in  ADT. 
put. line  (“change-merging  prototypes") ; 
put.line(“reading  base  version"); 

PROTOTYPE.NAME  :■  name.of. prototype  (BASE. VERSION) ; 
system,  call  ("aerge.  script  -p  "ABASE. VERSION. sA"  "A 

PROTOTYPE.NAME . sA">  "A"/tmp/temp.base_file.psdl") ; 
—  builds  single  file  input! 
open (BASEFILE ,  in.file,  "/tap/temp.base.f ile.psdl") ; 
assign (BASE , empty.psdl.program) ; 
get (BASEFILE , BASE) ; 
close (BASEFILE) ; 

system. call ("ra  /tap/temp.base.f ile.psdl") ; 
expand (BASE) ; 
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—  reads  in  first  modified  version  of  prototype  end  puts  in  ADT. 

put .line ("reading  1st  nodif ied  version") ;  * 

system. call ("merge . script  -p  "AVERSION.A . sA"  "A 

PROTOTYPE.NAME . sA">  "*"/tnp/tenp_a_f ile .padl") ; 

—  builds  single  file  input! 
open(AFILE,  in.file,  "/tmp/temp.a.f ile.psdl") ; 
assign (OPA , empt y.psdl.program) ; 

get ( AFILE , OPA) ; 
close (AFILE) ; 

system_call("r*  /tnp/tenp_a_f ile.psdl") ; 
expand (OPA) ; 

—  reads  in  second  modified  version  of  prototype  and  puts  in  ADT. 
put.line ("reading  2nd  modified  version"); 

system_call( "merge. script  -p  "AVERSION.B.sA"  "A 

PROTOTYPE.NAME . sA">  "A"/tnp/teap_b_f ile.psdl") ; 

—  builds  single  file  input! 
open(BFILE,  in.file,  "/tmp/temp.b.f ile.psdl") ; 
assign (OPB , empty.psdl.program) ; 

get (BFILE.OPB) ; 
close (BFILE) ; 

system. call ("m  /tmp/temp.b.f ile.psdl") ; 
expand(OPB) ; 

—  puts  result  of  performing  the  merge  into  the  directory  result. 
change.merge (BASE ,  OPA,  OPB,  MERGE,  CONFLICT); 

temp  :■  mkdir (result. s) ; 

split  (result .  PROTOTYPE.NAME  .MERGE) ; 

exception 
vhen  use.error  ■> 

put. line (standard.error , 

"error:  can't  create  output  file,  permission  denied."); 
vhen  syntax.error  ■> 

put. line (standard.error , 

"  parsing  aborted  due  to  syntax  error."); 
vhen  seaantic.error  ■> 
put .line (standard.error , 

"  semantic  errer,  parsing  aborted."); 
vhen  expander_pkg.no.root  ■> 
put .line (standard.error , 

"  semantic  error  -  no  top  level  operator,  expansion  aborted."); 
put .line (standard.error , 

"  check  for  recursive  use  of  the  prototype  name  in  an  expansion."); 
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vhen  expander .pkg .mult iple.ro ots  ■> 
p«t.UM(iti&dttd.«rror, 

M  semantic  error  -  more  than  on*  top  lovol  operator, 
expansion  aborted."); 
put .line ( »t andard. error , 

"  check  for  operators  that  are  not  used  or") ; 
put .line (standard. error , 

"  add  an  extra  top-level  operator  that  decomposes") ; 
put. line (standard. error, 

"  into  the  current  set  of  top-level  component s") ; 
put. line (standard. error , 

"  if  your  design  has  several  top-level  coaponents.") ; 

— when  undef ined. component  ■> 

—  put .line (standard. error, 

—  "  semantic  error  -  an  operator  vithout  a  PSDL  definition  has 

—  been  used."); 

when  prototype.path.error  ■> 

put.lineC'from  merge.main.pkg. merge") ; 
put .line (standard.error , 

"  path  to  merge  inputs  provided  by  top-level  interface  was 
incorrect . ") ; 
vhen  constraint.error  *> 
put .line (standard.error , 

"  constraint.error  -  merger  not  vorking  properly."); 
vhen  numeric.error  *> 

put .line (standard.error , 

"  numeric.error  -  merger  not  vorking  properly."); 
vhen  program. error  ■> 

put .line (standard.error , 

"  program. error  -  merger  not  vorking  properly.”); 
vhen  storage.error  »> 

put .line (standard.error , 

"  storage.error  -  merger  not  vorking  properly."); 
vhen  tasking_error  *> 

put. line (standard.error , 

"  tasking. error  -  merger  not  vorking  properly."); 
vhen  others  *> 

put. line (standard.error , 

"  unexpected  exception  -  merger  not  vorking  properly."); 
end  merge; 
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procedure  find. Base  (VERSION. A, 

VERSION.B  :  in  a.string; 

BASE. VERSION  :  in  out  a. string; 

ERROR  :  in  out  boolean)  is 

begin 

text. io. put. line ("this  procedure  is  not  yet  implemented") ; 

BASE. VERSION  :■  to_a("You  Bust  select  a  base  version  manually !"); 
ERROR  :*  true; 
end  find.Base; 

procedure  commit. serge  (BASE. VERSION, 

VERSION. A, 

VERSION.B  :  in  a.string; 

RESULT  :  in  out  a.string)  is 

in.result  :  a. string  :■  copy (RESULT) ; 
temp.string  :  a. string; 
temp  :  status. code; 

function  version_num(x  :  a.string)  return  a.string  is 

vnum  :  a. string; 
index  :  integer  :»  x.len; 

begin 

vhile  x.s (index)  /»  */*  loop 
index  :■  index  -  1; 
end  loop; 

vnum  :*  to_a(x.s(index+l. .x.len)); 
return  vnum; 
end  version.num; 

begin 

temp.string  :■  (in.result  Jfc  to_a("-")  k  version.num (VERSION. A) 

*  to.a(".")  k  vers i on.num (BASE. VERS ION) 

*  to.a(".")  k  version.num (VERSION.B)); 
temp  :•  mkdir (temp.string. s) ; 

sy stem. call ("mv  "  k  in.result. s  A  "/e.psdl  "  k  temp.string. s) ; 
temp  :■  rmdir (in.result. s) ; 

RESULT  :*  copy (temp.string) ; 
end  commit .merge; 
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•ad  merge_main; 

2.  change_merge_pkg 


•mm  »  wjppiipjpytpiiiyii]  ■•*  «*'•»»  » 


COMPONENT  NAME 
USAGE 

INPUT/OUTPUT 


—  AUTHOR 

—  DATE  OF  CREATION  : 

—  LANGUAGE  USED 

—  COMPILER  USED 

—  PURPOSE 

—  FILES  USED 


NOTES 


PACKAGE  CHANGE.MERGE.PKG  (  change.merge.pkg_s . a  ) 

BASE,  A,  B:  in  psdl.program 
MERGE:  in  out  psdl.program 
CONFLICT:  out  boolean 
Dave  Dampier 
19  April  1994 
Ada 

Sun  Ada  1.0 

Contains  th«  procedure  which  performs  the  change-merge 
operation  on  PSDL  programs, 
psdl.type.s.a,  psdl.ct.s.a,  psdl_prog_s.a, 
psdl_graph_s .a,  prototype_dependency_graph_pkg_s .a, 
proto _spec_aerge_pkg_s . a,  proto. impl_merge_pkg_s .a, 
•zp.s.a. 


with  a_ strings ;  use  a_strings; 

with  psdl.component.pkg;  use  psdl.component.pkg; 

with  psdl.concrete.type.pkg;  use  psdl.concrete.type.pkg; 

with  psdl.program.pkg;  use  psdl.program.pkg; 

with  psdl.graph.pkg;  use  psdl.graph.pkg; 

with  prototype_dependency.graph.pkg;  use  prototype_dependency_graph_pkg; 

with  proto.spec.merge.pkg;  use  proto_spec.merge.pkg; 

with  proto.impl.merge.pkg;  use  proto.impl_merge.pkg; 

with  tert.io;  use  tezt.io; 

with  expression_pkg;  use  expression_pkg; 

package  change.merge.pkg  is 
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—  This  function  performs  the  change.merge  operation  on  PSDL  prototypes.  •<— 
--  Given  three  prototypes,  BASE,  A  and  B,  the  function  creates 

—  prototype  dependency  graphs  for  the  three  prototypes,  and  using 

—  prototype  slicing,  it  identifies  the  preserved  part  of  the  base 

—  in  all  three  versions,  and  the  parts  of  the  changed  versions  which 

—  are  different  from  the  base.  It  then  combines  the  three  pieces  into  — 

—  a  Barged  graph.  If  the  graph  correctly  represents  the  semantic  merge  — 

—  of  the  three  versions,  and  there  are  no  conflicts,  then  the  merged 

—  prototype  is  reconstructed  from  the  merged  graph.  In  the  case  of  a 

—  conflict,  the  exception  "marge.conflict"  is  raised. 


procedure  change.merge (BASE,  A,  B:  in  psdl.program; 

MERGE:  in  out  psdl.program; 

CONFLICT:  out  boolean); 

procedure  build.prototype(P:  in  out  psdl.component ; 

G:  in  prototype. dependency .graph) ; 

end  change.merge.pkg; 


package  body  change.merge.pkg  is 


—  This  function  performs  ths  change.merge  operation  on  PSDL  prototypes. 

—  Given  three  prototypes,  BASE,  A  and  B,  the  function  creates 

—  prototype  dependency  graphs  for  the  three  prototypes,  and  using 

—  prototype  slicing,  it  identifies  the  preserved  part  of  the  base 

—  in  all  three  versions,  and  the  parts  of  the  changed  versions  which 

—  are  different  fron  the  base.  It  then  combines  the  three  pieces  into  a 

—  merged  graph.  If  the  graph  correctly  represents  the  semantic  merge 

—  of  the  three  versions,  and  there  are  no  conflicts,  then  the  merged 

—  prototype  is  reconstructed  from  the  merged  graph. 


procedure  change jeerge (BASE,  A,  B:  in  psdl.program; 

MERGE:  in  out  psdl.program; 

CONFLICT:  out  boolean)  is 

BASEHGLD,  AHOLD,  BHOLD:  psdl.program  :•  empty .psdl.program; 

BASETYPE ,  ATYPE,  BTYPE:  psdl.program  :*  empty .psdl.program; 

ATOMIC.COMP :  at omic.operat or ; 

BASECOMP,  ACOMP,  BCOMP,  MERGECOMP:  composite. operator; 

GBASE,  GA,  GB,  GM,  PP,  APA,  APB:  prototype.dependency .graph; 

BASESTREAMS ,  ASTREAMS,  B STREAMS,  HERGESTREAMS :  type.declaration; 
MERGESTATES :  type.declaration; 

MERGEINIT:  ini t .map  :■  empty. ini t. map ; 

MERGEEXCEPTIONS ,  MERGEKEYVORDS :  id. set; 

MERGEMET:  millisec  :*  0; 

MERGE. INF.DESC ,  MERGE.AX:  text; 

BASETRIG,  ATRIG,  BTRIG,  MERGETRIG:  trigger .map  :■  empty.trigger.map ; 
BASEEG,  AEG,  BEG,  MERGEEG:  exec.guard.map  :■  empty.exec.guard.map; 
BASEOG,  AOG,  BOG,  MERGEOG:  out.guard.map  :*  empty_out.guard.map; 

BASEET,  AET,  BET,  MERGEET:  excep. trigger .map  :*  empty. excep.trigger.map; 
BASETO,  ATO,  BTO,  MERGETO:  timer. op .map  :«  empty.timer.op.map; 

BASEPER,  APER,  BPER,  MERGEPER:  ti«ing_map  :■  empty. timing_map; 

BASEFV,  AFV,  BFW,  MERGEFV:  timing.. sap  :■  empty.timing.map; 
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BASEMCP,  AMCP,  BMCP,  NERGEHCP:  timing. map  :*  •apty.timing.map ; 
BASEMRT,  AMRT,  BMRT,  NERGEKRT:  timing  map  :■  empty .timing. map ; 
BASEDESC,  ADESC,  BDESC,  MERGEOESC:  text; 

HERGEID:  psdl .id; 

BASETIMERS,  ATIMERS,  BTIMERS,  HERGETIMERS,  V:  id. set; 
tempexpression:  expression; 
tmmpoutid:  output. id; 
temperid:  mxcmp.id; 

conflict .free.a,  conf  licrt.f  ree.b :  boolean  :■  true; 


begin 


conflict  :■  false; 


This  section  of  code  is  used  to  extract  the  psdl  components  from  each 
of  the  three  programs.  It  assigns  the  parent  composite  operator  to  its 
own  component  variable,  and  it  assigns  the  atomic  operators  to  holding 
components,  so  they  can  be  retrieved  later. 


—  BASE 


for  id:psdl_id,c:psdl_component  in  psdl_program.map.pkg . scan (BASE)  loop 
if  component.category(c)  *  psdl. type 
then 

bind(id,c,BASETYPE) ; 

else 

if  component  .granularity  (c)  ■  composite 
then 

BASECOMP  c; 

else 

bind(id,  c,  BASEHOLD); 
end  if; 
end  if; 
end  loop; 
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for  id:psdl.id,c:psdl_coaponant  in  psdl.prograa_nap.pkg. scan (A)  loop 
if  coaponant.catagory(c)  *  psdl.typo 
than 

bind(id.c.ATYPE); 

•Iso 

if  coaponant .granularity (c)  *  coaposita 
than 

ACOMP  c; 

also 

bind (id,  c,  AHOLD); 
and  if; 
and  if; 
and  loop; 


—  B 


for  id : psdl.id , c : psdl. coaponant  in  psdl.prograa_aap.pkg. scan (B)  loop 
if  coaponant.catagory(c)  *  psdl.typo 
than 

bind(id.c.BTYPE); 

also 

if  coaponont .granularity (c)  ■  coaposita 
than 

BCOMP  :■  c; 

also 

bindCid,  c,  BHOLD); 
and  if; 
and  if; 
and  loop; 
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Create  the  Merged  Specification 


Merge  the  states 


aerge_states(MERGESTATES, states (BASECOMP) , states (ACOMP) .states (BCOMP) , 
MERGEINIT,  get.init jsap(BASECOMP) ,  get.init.aap (ACOMP) , 
get.init.aap (BCOMP) ) ; 


—  Merge  the  Exceptions 


assign (MERGEEXCEPTIONS ,  aerge.id.sets  (exceptions (BASECOMP) , 

exceptions (ACOMP) ,  exceptions (BCOMP) ) ) ; 


—  Merge  the  Keywords 


assign (MER6EKEYV0RDS ,  aerge.id.sets (keywords (BASECOMP) , 

keywords (ACOMP) ,  keywords (BCOMP) )) ; 


—  Merge  the  Inforaal  Description 


MERGE.IMF.DESC  :*  aerge. text (inforaal .descript ion (BASECOMP) , 

inf oraal.description (ACOMP) , 
inf oraal.descript ion (BCOMP)) ; 


—  Merge  the  Foraal  Description 


MERGE. AX  :■  aerge. text (axioas (BASECOMP) , 

axioas (ACOMP) , 
axioas (BCOMP) ) ; 


—  Merge  the  Mariana  Execution  Tim* 


MERGEMET  :•  aerge.aet (specif ied_aaxinua_ execution.tiae (BASECOMP) , 

specif i ed.aaxiaua. execut ion.t ime ( ACOMP ) , 
spec if i ed.aax iaua. exe cut i on.t iae ( BCOMP ) ) ; 


—  Merge  the  Iapleaentation 


—  Extract  the  prototype  dependency 

—  graphs  frba  the  psdl  conponents . 


assignCGBASE,  build.PDG(BASECOMP)) ; 
assign (GA ,  build.PDG (ACOMP) ) ; 
assignCGB,  build_PDG (BCOMP) ) ; 


—  Create  the  Preserved  Part 


assign(PP,  preserved_part(GBASE,  GA,  GB)); 


—  Create  the  Affected  Parts  of  each 

—  aodification  graph. 


—  put. line ( "Affected  Part:  A"); 

assign (APA,  affect ed_part(GA,  GBASE));  —  First  Modification 

—  put .line ("Affected  Part:  B”); 

assign (APB,  affected_part(GB,  GBASE));  Second  Modification 
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assign (BASESTBEAMS ,  streams (BASECOMP) ) ; 
assign (ASTREAMS,  streams (ACOMP)) ; 
assign (BSTREAMS,  straaas(BCONP)) ; 

assign (MERGESTREAMS ,  merge .streams (BASESTREAMS ,  ASTREAMS,  BSTREAMS) )  ; 


—  Marga  tha  timers 


assign (BASETIMERS .  timers (BASECOMP) ) ; 
assign (ATIMERS,  timers (ACOMP) ) ; 
assign (BTIMERS,  timers (BCOMP) ) ; 

assign (MERGETIMERS ,  marga.timers (BASETIMERS ,  ATIMERS,  BTIMERS)); 


—  Marga  tha  triggers 


for  id:  psdl.id  in  id.set.pkg . scan (vert ices (GBASE) )  loop 
if  not  eq(id,  EXT) 
than 

bind(id,  get_trigger(id,  BASECOMP),  BASETRIG); 
and  if; 
and  loop; 

for  id:  psdl.id  in  id_sat_pkg. scan (vart ices (GA))  loop 
if  not  eq(id,  EXT) 
than 

bind(id,  gat .trigger (id,  ACOMP),  ATRIG); 
and  if; 
and  loop; 
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tor  14:  padl.id  in  id.sat.pkg. scan(Tsrticaa (GB) )  loop 
if  mot  oq(id,  EXT) 
than 

bind (id,  gat_triggar(id,  BCOMP) ,  BTRIG) ; 
and  if; 
and  loop; 

assign (MERGETRIG,  narga.triggar.naps (varticas (GM) , 

BASETRIG,  ATRIG,  BTRIG)); 


Morgo  tha  oxocution  guards 


for  id:  psdl.id  in  id.sot.pkg . scan (varticas (GBASE) )  loop 
if  not  aq(id,  EXT) 
than 

bind (id,  axacution_guard(id,  BASECOMP),  BASEEG) ; 
and  if; 
and  loop; 

for  id:  psdl.id  in  id.sat.pkg . scan (varticas (GA) )  loop 
if  not  aq(id,  EXT) 
than 

bind (id t  axacution_guard(id,  ACOMP) ,  AEG); 
and  if; 
and  loop; 

for  id:  psdl.id  in  id.sat.pkg . scan (varticas (GB) )  loop 
if  not  aq(id,  EXT) 
than 

bind(id,  axacution_guard(id,  BCOMP),  BEG); 
and  if; 
and  loop; 

assign (MERGEEG,  narga.axac.guard.naps  (varticas  (GM) , 

BASEEG,  AEG,  BEG)); 


—  Merge  the  output  guards 


for  •:  edge  in  edge.set.pkg. scan (edges (GBASE))  loop 

assign (taapaxprassion, output .guard (e .x , • . straaa.naae .BASECQMP) ) ; 
if  not (taapaxprassion  *  truo.axprossion) 
than 

taapoutid.op  :«  copy (a. x); 
taapoutid. straaa  :■  copy (a. straaa.naae) ; 
bind (taapoutid,  taapaxprassion,  BASEOG) ; 
and  if; 
and  loop; 

for  a:  adga  in  adga.sat.pkg.scan(adgas(GA))  loop 

assign (taapaxprassion , output .guard (a . x , a . strean.naae , ACOMP) ) ; 
if  not (taapaxprassion  ■  trua.exprassion) 
than 

taapoutid.op  :«  copy (a. x); 
taapoutid. straaa  :■  copy(a.streaa.naae) ; 
bind (taapoutid,  taapaxprassion,  AOG); 
and  if; 
and  loop; 

for  a:  adga  in  adga_sat.pkg.8can(adgas(GB))  loop 

assign (taapaxprassion, output .guard(e .x , a . straaa.naae .BCOMP) ) ; 
if  not (taapaxprassion  ■  trua.axprassion) 
than 

taapoutid.op  :■  copy(a.x); 
taapoutid.  straaa  :■  copy  (a.  straaa.naae)  ; 
bind(taapoutid,  taapaxprassion,  BOG); 
and  if; 
and  loop; 

assign (MERGEOG,  aarga.output .guard.aaps (BASEOG, AOG, BOG) )  ; 


—  Marga  tha  axcaption  triggers 
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■  -W  ,  ' 


lor  id:  padl.id  in  id_set_pkg.scan(vertices(GBASE))  loop 
if  not  eq(id,  EXT) 
than 

for  •:  padl.id  in  id.set _pkg.scan(except ions (BASECOMP))  loop 
assign (tenpezpression,  exceptien_trigger(id,e, BASECOMP)) ; 
if  not  eq(tenpexpression,  falsa. expression) 
then 

tenpezid. op  :•  copy(id); 
tenpezid . ezcep  :»  copy(e); 
bindCtenpezid,  tenpezpression,  BASEET); 
end  if; 
end  loop; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set .pkg. scan (vert ices (GA))  loop 
if  not  eq(idt  EXT) 
then 

for  e:  psdl.id  in  id.set. pkg. scan(exceptions(ACOMP))  loop 
assign (tenpezpression,  exception_trigger(id,e,ACOMP)) ; 
if  not  eq(tenpexpression,  false. expression) 
then 

tenpezid. op  :■  copy(id); 
tenpezid. ezcep  :■  copy(e); 
bind (tenpezid,  tenpezpression,  AET); 
end  if; 
end  loop; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set. pkg. scan (vertices (GB))  loop 
if  not  eq(id,  EXT) 
then 

for  e:  psdl.id  in  id.set.pkg.scan(ezceptions(BCOMP))  loop 
assign(te'»pexpression,  exception.trigger(id,e,BCOMP)) ; 
if  not  eq (tenpezpression,  false. expression) 
then 

tenpezid. op  :«  copy(id); 
tenpezid. ezcep  :*  copy(e); 
bind (tenpezid,  tenpezpression,  BET); 
end  if; 
end  loop; 
end  if; 
end  loop; 

ass ign(MERGEET,(nerge.ezcep.trigger.naps (BASEET,  AET,  BET))); 
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Merge  the  tiaer  operations 


for  id:  psdl.id  in  id.set.pkg. scan (vert ices (GBASE))  loop 
if  not  eq(id,  EXT) 
then 

bind(id,  tiaer. operations (id,  BASECOMP) ,  BASETO) ; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set.pkg. scan (vert ices (GA))  loop 
if  not  eq(id,  EXT) 
then 

bind(id,  tiaer.operations(id,  ACOMP),  ATO) ; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set.pkg. scan (vert ices (GB))  loop 
if  not  eq(id,  EXT) 
then 

bind(id,  tiaer.operations(id,  BCOMP),  BTO); 
end  if; 
end  loop; 

assign (MERGETO,  aerge_tiaer.op.aaps (vertices (GM) ,  BASETO,  ATO,  BTO)); 

—  Merge  the  periods 

for  id:  psdl.id  in  id.set_pkg. scan (vert ices (GBASE))  loop 
if  not  eq(id,  EXT) 
then 

bind(id,  period (id,  BASECOMP),  BASEPER) ; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set.pkg. scan(vertices(GA))  loop 
if  not  eq(id,  EXT) 
then 

bind(id,  period(id,  ACOMP),  APER); 
end  if; 
end  loop; 
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for  id:  psdl.id  in  id.set.pkg .  scan (vertices (GB)  )  loop 
if  not  eq(id,  EXT) 
tlioa 

bind (id,  poriod(id,  BCOHP),  BPER); 
ond  if; 
ond  loop; 

assign(MERGEPER,  nerge.period (BASEPER ,  APER,  BPER)); 


—  Morgo  tho  f inish.vithins 


for  id:  psdl.id  in  id.set.pkg. scan(vertices(GBASE))  loop 
if  not  eq(id,  EXT) 
than 

bind (id,  finish_within(id,  BASECONP) ,  BASEFV) ; 
ond  if; 
ond  loop; 

for  id:  psdl.id  in  id.set.pkg . scan (vertices (GA) )  loop 
if  not  eq(id,  EXT) 
thon 

bind (id,  finish. within (id,  A COMP) ,  AFV); 
ond  if; 
ond  loop; 

for  id:  psdl.id  in  id.set.pkg . scan (vortices (GB) )  loop 
if  not  eq(id,  EXT) 
thon 

bind (id,  finish_within(id,  BCOMP),  BFV); 
ond  if; 
ond  loop; 

assign (MERGEFV,  norgo.fw_or.nrt (BASEFW,  AFV,  BFV)); 


—  Morgo  tho  naz  response  tines 


for  id:  psdl.id  in  id.set.pkg. scan (vert ices (GBASE))  loop 
if  not  eq(id,  EXT) 
thon 

bind(id,  naximum_response_tine(id,  BASECOMP),  BASEMRT); 
ond  if; 
ond  loop; 
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for  id:  psdl.id  in  id.aet.pkg. scan (vertices (GA))  loop 
if  not  eqCid,  EXT) 
than 

bindCid,  aaxiBun.response.tiaeCid,  ACOMP),  AMRT) ; 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.8«t.pkg.8can(v«rticss(GB))  loop 
if  not  eqCid,  EXT) 
than 

bindCid,  aaxiaua.response.tiaeCid,  BCOMP) ,  BMRT); 
•nd  if; 

•nd  loop; 

assign(MERGEMRT,  aerge_f v_or_mrt (BASEMRT ,  AMRT,  BMRT)); 


—  Merge  the  ainiaua  calling  periods 


for  id:  psdl.id  in  id.set.pkg.scanCverticesCGBASE))  loop 
if  not  «q(id,  EXT) 
then 

bindCid,  ninintm_calling_p«riod(id,  BASECOMP) ,  BASEMCP); 
•nd  if; 

•nd  loop; 

for  id:  psdl.id  in  id. set .pkg. scan (vert i css (G A))  loop 
if  not  «q(id,  EXT) 
then 

bindCid,  ■ininun.calling.periodCid,  ACOMP),  AMCP); 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set_pkg.scan(v«rtic«s(GB))  loop 
if  not  eqCid,  EXT) 
then 

bindCid,  sininun.call ing.par i od C id ,  BCOMP),  BMCP); 
end  if; 
end  loop; 

assign CMERGEMCP,  narge.sin_call_per CBASEMCP ,  AMCP,  BMCP)); 
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Merge  tke  implementation  descriptions 


BASEDESC  :■  iaplamentation.description(BASECOMP) ; 

ADESC  :»  implementation.description(ACOMP) ; 

BDESC  :•  implement at ion_dascri.pt ion (BCOMP) ; 

MERGEDESC  :■  marge, implement at ion.descript i on (BASEDE1SC ,  ADESC,  BDESC); 


—  Construct  tha  aargad  program. 


KERGEID  copy (name (BASECOMP)) ; 

MERGECONP  ;»  make.composite_operator(MERGEID, 

keywords  »>  MERGER EYWORDS , 

informal.description  ■>  MERGE. INF. DESC, 

axioms  ■>  MERGE.AX , 

state  ■>  MERGESTATES, 

initialization.map  *>  MERGEINIT, 

exceptions  ■>  MERGEEXCEPTIONS , 

specif ied.met  ■>  MERGEMET, 

streams  ->  MERGESTREAMS , 

timers  *>  MERGETIMERS, 

trigger  »>  MERGETRIG , 

exec_guard  *>  MERGEEG, 

out .guard  ■>  MERGEOG, 

excep.t rigger  *>  MERGEET, 

timer. op  ■>  MERGETO, 

per  •>  MERGEPER, 

fv  ■>  MERGEFW, 

mcp  •>  MERGEMCP, 

mrt  ■>  MERGEMRT, 

impl.desc  ■>  MERGEDESC); 


—  Compare  the  the  Merged  Graph  with  the  Graph  of  each  modification  by 

—  comparing  the  slices  of  each  vith  respect  to  their  affected  parts. 

—  If  the  slices  are  the  same,  then  the  merged  graph  is  correct  and  the 

—  program  can  be  rebuilt.  Otherwise,  there  is  a  conflict  that  must  be 

—  resolved . 


build_prototype(MERGECOMP,  GM); 
conflict .free.a  :*  compare_graphs (GM ,  GA,  APA); 
conflict. free.b  :*  compare_graphs(GM,  GB,  APB); 
if  not  conflict.free.a 
then 

put_line( "Conflict  found  in  Version.A"); 
conflict  :*  true; 
end  if; 

if  not  conflict.free.b 
then 

put.line ("Conflict  found  in  Version.B") ; 
conflict  :<■  true; 
end  if; 


—  Return  the  Merged  Program. 


bind (MERGEID , MERGECOMP , MERGE) ; 

assign(V,  vertices (PP) ) ; 
for  id:  psdl.id  in  id.set.pkg.scan(V)  loop 
bind(id,fetch(BASEHOLD,id) , MERGE) ; 
end  loop; 

assignCV,  vertices (APA) ) ; 
for  id:  psdl.id  in  id.set.pkg.scan(V)  loop 
if  not  member (id, MERGE) 
then 

bind(id, fetch (AHOLD, id) .MERGE) ; 
end  if; 
end  loop; 

assign(V,  vert ices (APB) ) ; 
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m 


f«r  id:  psdl.id  la  id.set.pkg .  scan(V)  loop 
if  mot  neaberC id, MERGE) 
thorn 

bind(id,f etch(BHOLD, id) .MERGE) ; 
ond  if; 
ond  loop; 

oad  change.aerge ; 


—  This  procedure  is  used  to  build  tho  morgod  prototype  when  the  change- 

—  merge  operation  is  successful. 


procedure  build.prot otype (P :  in  out  psdl.coaponent ; 

G:  in  prototype. dependency .graph)  is 


A:  psdl.graph; 
begin 

assign (A,  psdl.graph(G)) ; 
remove_vertez(EXT,  A); 
set .graph (A, P) ; 
end  build.prototype; 

end  change.merge.pkg; 
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3.  proto _spec.merge.pkg 


—  COMPONENT  NAME  :  PACKAGE  PROTO_SPEC.MERGE.PKG (proto.spec.serge.pkg. s .a) 

—  AUTHOR  :  Dave  Daspier 

—  DATE  OF  CREATION:  19  April  1994 

—  LANGUAGE  USED  :  Ada 

—  COMPILER  USED  :  Sun  Ada  1.0 

—  PURPOSE  :  This  package  provides  specifications  for  the  functions 

—  used  to  perform  change-serges  on  psdl  operator 

—  specifications. 

—  FILES  USED  :  psdl.ct.s.a,  psdl.ct.b.a,  psdl_type_s .a,  psdl.type.b.a, 

—  set.s.a,  set.b.a,  nap.s.a,  sap.b.a,  exp.s.a,  erp.b.a. 

vith  system; 
with  generic.aap.pkg; 
vith  generic.set.pkg; 
with  TEXT.IO; 
vith  a.st  rings; 
vith  psdl_concrete.type.pkg; 
vith  psdl.cosponent _pkg ; 
vith  express ion.pkg; 

package  proto.spec.serge.pkg  is 

function  MERGE.  SEQUENCES  (BASE,  A,  B:  type.dedaration) 
return  type.dedaration; 

procedure  MERGE.STATES (MERGE:  in  out  type.dedaration; 

BASE,  A,  B:  in  type.dedaration; 

MERGEINIT:  in  out  ini t. sap; 

BASEINIT,  AINIT,  BINIT:  in  init.aap); 

function  MERGE.MET(BASE,  A,  B:  sillisec)  return  sillisec; 

function  MERGE. ID.SETS (BASE,  A,  B:  id.set)  return  id.set; 

function  MERGE. TEXT (BASE ,  A,  B:  text)  return  text; 

end  proto.spec.serge.pkg; 


use  TEXT.IO; 
use  a_strings; 
use  psdl.concrete.type.pkg; 
use  psdl.cosponent.pkg; 
use  expression.pkg; 
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fftafi  body  proto. spec jeorgo.pkg  ia 


function  serge. sequences (BASE,  A,  B:  type .declaration) 
roturn  typo.doclaration  ia 

MERGE  :  typo.doclaration; 

TOP  :  constant  psdl.id  :■  to.aC'TOP") ; 

bogin 

aaaign (MERGE,  ospty.typo.dodaration) ; 
if  equal (BASE,  A) 
than  if  oqual(BASE,  B) 
than  assign (MERGE,  BASE); 
also  assign (MERGE,  B); 
and  if; 

also  if  aqual(BASE,  B) 
than  assign (MERGE,  A); 
also  if  aqnal(A,  B) 
than  assign (MERGE,  A); 
also  bind (TOP,  null. typo,  MERGE); 
and  if; 
and  if; 
and  if; 
roturn  MERGE; 
and  aarga.saquancas; 

function  aorgo.typos (t.b&sa ,  t.a,  t.b  :  typa.nasa)  return  type.naae  is 
begin 

if  equal (t. base,  t.a) 
than 

if  equal (t. base,  t.b) 
than 

return (t. base) ; 

else 

return (t.b) ; 
and  if; 
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else 

if  equal (t.base,  t.b) 
then 

return(t.a) ; 

else 

if  equal (t. a,  t.b) 
then 

return (t.a) ; 

else 

return  null. type; 
end  if; 
end  if; 
end  if; 

end  serge. types; 

procedure  serge.states (MERGE:  in  out  type.declaration; 

BASE,  A,  B:  in  type.declaration; 

MERGEINIT :  in  out  ini t .map; 

BASEINIT ,  AIMIT,  BINIT:  in  init .sap)  is 

init.value  :  expression; 

base. type,  a. type,  b.type  :  type.nase; 

begin 

assign(init. value,  eapty.expression) ; 
assign (MERGE,  espty .type.declaration) ; 

for  id:  psdl.id,  t:  type.nase  in  type.declaration.pkg. scan (BASE)  loop 
if  »eaber(id,  A)  and  sesber(id,  B) 
then 

a.type  :«  type_declaration_pkg.fetch(A,id) ; 
t>_type  :■  type.declaration.pkg. f etch (B, id) ; 
bind(id,  serge_types(t,  a.type,  b.type),  MERGE); 
assign(init. value,  init .sap.pkg. fetch (BASEINIT, id) ) ; 
if  eq(init .value ,  init.sap.pkg . f etch(AINIT,  id)  ) 
then 

if  eq( init.value , init .sap.pkg . fetch (BINIT , id) ) 
then 

bind (id. init. value, MERGEINIT) ; 

else 

bind (id, init .sap.pkg. fetch (BINIT, id) .MERGEINIT) ; 
end  if; 
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•iM 

if  eq(init_Talue , init.nap.pkg . fetch (BIMIT , id) ) 
then 

bind ( id , init.nap.pkg . f at cb (AINIT , id) , MERGEINIT) ; 

•1m 

if  eq( init.nap.pkg. fetch (AINIT, id) , 

init.nap.pkg .f at ch (BINIT, id) ) 

than 

bind (id, init.nap.pkg .fetch (AINIT, id) , MERGEINIT) ; 

alsa 

bind (id, conflict .expression, MERGEINIT) ; 
and  if; 
and  if; 
and  if; 
and  if; 
and  loop; 

for  id:  psdl.id,  t:  type.nane  in  type.declaration.pkg.scan(A)  loop 
if  not  naabar(id,  BASE)  and  nanbarCid,  B) 
than 

base.typa  :»  null.type; 
b-typa  :■  typa_daclaration_pkg.fatch(B,id) ; 
bind(id,  nerge. types (base.typa ,  t,  b.type) ,  MERGE); 
assign(init_value,  init.nap.pkg • fat ch (AINIT , id) ) ; 
if  aq(init.valua ,  init.nap.pkg . fatch (BINIT,  id)  ) 
than 

bind (id , init .value , MERGEINIT) ; 

alsa 

bind (id, conflict. express ion, MERGEINIT) ; 
and  if; 
and  if; 
and  loop; 
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for  id:  psdl.id,  t:  type.nane  in  type.declaration.pkg.scan(B)  loop 
if  not  aeaber(id,  BASE)  and  neaber(id,  A) 
than 

base.type  :*  null.type; 

a. typo  :■  type.declaration.pkg.f etch(A,id) ; 
bind(id,  nerge.types (base.type,  a_type,  t) ,  MERGE); 
assign(init.value,  init.aap.pkg. fetch (BINIT, id)) ; 
if  oq(init .value , init.aap.pkg . fetch (AINIT, id) ) 

then 

bind(id,init_value,MERGEINIT) ; 

else 

bind (id, conf 1 ict_ express i on , MERGEINIT) ; 
end  if; 
end  if; 
end  loop; 
end  serge. states ; 

function  aerge.net (BASE,  A,  B:  aillisec)  return  aillisec  is 
A.DIFF.BASE,  B.DIFF.BASE ,  A.INT.B:  aillisec; 
begin 

if  A  <«  B 

then  A.INT.B  :»  B; 
else  A.INT.B  :«  A; 
end  if; 
if  BASE  <-  A 

then  A.DIFF.BASE  :»  syst ea . aax.int ; 
else  A.DIFF.BASE  :■  A; 
end  if; 
if  BASE  <-  B 

then  B.DIFF.BASE  :*  system. aax.int; 
else  B.DIFF.BASE  :■  B; 
end  if; 

if  A.DIFF.BASE  <»  A.INT.B 
then  if  A.DIFF.BASE  <»  B.DIFF.BASE 
then  return  A.DIFF.BASE; 
else  return  B.DIFF.BASE; 
end  if; 

else  if  A.INT.B  <«  B.DIFF.BASE 
then  return  A.INT.B; 
else  return  B.DIFF.BASE; 
end  if; 
end  if; 

end  nerge.aet; 
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Ittetiok  m|i.id.wt» (Mg,  A,  B:  id. set)  return  id.set  is 
A.DIFF.BASE,  B.DIFF.BASE,  MERGE:  id.set; 
begin 

assign (A.DIFF.BASE,  eapty.id.set) ; 
assign (B.DIFF.BASE,  eapty.id.set) ; 
assign (MERGE,  aapty.id.sst) ; 
difference (A,  BASE,  A.DIFF.BASE) ; 
difference (B,  BASE,  B.DIFF.BASE); 
for  id:  psdl.id  in  id.set.pkg.scan(A)  loop 
if  aeaberCid,  B) 
then 

add (id,  MERGE); 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set.pkg.scan(A.DIFF_BASE)  loop 
if  not  aeaberCid,  MERGE) 
then 

add(id,  MERGE); 
end  if; 
end  loop; 

for  id:  psdl.id  in  id.set.pkg. scan (B.DIFF.BASE)  loop 
if  not  aeaberCid,  MERGE) 
then 

addCid,  MERGE); 
end  if; 
end  loop; 
return  MERGE; 
end  aerge.id.sets; 
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function  sorgo. tort  (BASE,  A,  B:  tort)  roturn  tort  is 
bog  in 

if  oq(BASE,  oapty.tozt)  and  oq(A,  onpty.text)  and  oq(B,  enpty.text) 
than  roturn  onpty.tort; 
olso  if  oq(BASE,  A) 
thon  if  not  oq(BASE,  B) 
thon  roturn  B; 
olso  roturn  BASE; 
ond  if; 

olso  if  oqCBASE,  B) 
thon  roturn  A; 
olso  if  oq(A,  B) 
thon  roturn  A; 

olso  roturn  to.a("**Toxt  Conflict**") ; 
ond  if; 
ond  if; 
ond  if; 
ond  if; 

ond  aerge.toxt; 
ond  proto.spoc.sorgo.pkg; 
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4.  protoJmpl_merge_pkg 


"  COMPONENT  NAME  :  PACKAGE  PROTO. IMPL.MERGE.PKG (proto. impl.merge.pkg.s 

—  USAGE  :  Used  to  perform  Change-Merging  on  PSDL  program 

—  implementations. 

—  AUTHOR  :  David  A.  Dampier 

—  DATE  OF  CREATION  :  19  April  1994 

—  LANGUAGE  USED  :  Ada 

—  COMPILER  USED  :  Sun  Ada  1.0 

PURPOSE  :  Provides  specifications  for  the  functions  necessary 

—  to  merge  PSDL  Implementations. 


with  system; 

with  TEXT.IO;  use  TEXT. 10; 
with  a.strings ;  use  a_strings; 
with  generic.map.pkg ; 
with  generic.set _pkg ; 

with  psdl.concrete.type.pkg;  use  psdl.concrete.type.pkg; 
with  psdl. component _pkg ;  use  psdl.component.pkg ; 
with  proto. spec.merge.pkg ;  use  proto.spec.merge.pkg ; 
with  expression_pkg;  use  expression.pkg ; 

package  prot o_ impl.merge.pkg  is 

function  merge. streams  (BASE,  A,  B:  type.dedaration) 

return  type.dedaration; 

function  merge.timers(BASE,  A,  B:  id.set)  return  id.set 
renames  proto.spec.merge.pkg .merge.id.sets ; 

function  merge.trigger.maps (VERTS:  id.set;  BASE,  A,  B:  trigger.map) 

return  trigger.map; 

function  merge.exec_guard.maps (VERTS :  id.set;  BASE,  A,  B:  exec.guard.map) 

return  exec_guard_map ; 


fraction  uerge. output .guard_uaps (BASE ,  A,  B:  out.guard.unp) 

return  out.guard.uap 

fraction  nerge.ezcep.t rigger .uaps (BASE,  A,  B:  ezcep.trigger.uap) 

return  ezcep.trigger.uap 

fraction  aerge.tiaer.op.naps (VERTS:  id.set;  BASE,  A,  B:  tiner.op.nap) 

return  timer.op.map 

fraction  uerge.period(BASE,  A,  B:  tining_aap)  return  tining.nap; 

fraction  uerge.fv.or. art (BASE,  A,  B:  tining_aap)  return  timing.nap; 

fraction  uerge.uin.call.per (BASE,  A,  B:  tiuing_nap)  return  timing.map; 

fraction  uerge.iupleuentation.description(BASE,  A,  B:  tezt)  return  tezt 
renaues  proto. spec.uerge.pkg . uerge. t ext ; 

end  proto,  iupl.uerge.pkg; 


p«clng«  body  proto_i*pl_*erge_pkg  is 

function  nerge.types (t .base,  t.a,  t.b  :  type.nane)  return  type.nane  is 
begin 

if  equal (t.base ,  t.a) 
then 

if  equal (t .buss,  t.b) 
then 

return (t.base) ; 

else 

return (t.b) ; 
end  if; 

else 

if  equal (t.base,  t.b) 
then 

return(t.a) ; 

else 

if  equal (t. a,  t.b) 
then 

return (t.a) ; 

else 

return  null.type; 
end  if; 
end  if; 
end  if; 

end  nerge.types; 

function  aerge.streans (BASE,  A,  B:  type.dsdaration) 
return  type.dedaration  is 
MERGE:  type.dedaration; 
base. type,  a. type,  b.type  :  type.nane ; 


begin 

assign  (MERGE,  enpty.type.dedaration) ; 

for  id:  psdl.id,  t:  type_nane  in  type.dedaration.pkg.scan(BASE)  loop 
if  nenber(id,  A)  and  nenber(id,  B) 
then 

a. type  :»  type.dedaration.pkg.fetch(A,id); 

b. type  :■  type.declaration.pkg.fetch(B.id) ; 
bind  (id,  nerge.types  (t,  a_type,  b.type),  MERGE); 

end  if; 
end  loop; 
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far  id:  psdl.id,  t:  type.naaa  is  type.declarat ion.pkg . scan (A)  loop 
if  net  aeaberCid,  BASE)  and  aeaber(id,  B)  ■' 

than 

basa.typa  :■  null. typo; 

b.typo  :■  type.declaration.pkg.fetch(B,id) ; 
bind (id, Barge .types (basa.typa,  t,  b.type),  MERGE); 
and  if; 
and  loop; 

for  id:  psdl.  t:  type.naaa  in  type.declarat ion.pkg. scan(B)  loop 
if  not  neal  vid,  BASE)  and  aeaberCid,  A) 
than 

basa.typa  :■  null.typa; 

a.type  :■  type.declarat ion.pkg. fetch(A, id) ; 
bind(id,narga_typas(basa.typa,a_typa,  t),  MERGE); 
and  if; 
and  loop; 
ratnrn  MERGE; 
and  narga.straans ; 

function  aarga.tr iggars (BASE ,  A,  r :  triggar)  ratnrn  trigger  is 
MERGE:  triggar; 

conflict .trigger  :  triggar  :*  (tt  ■>  by. all, 

straaas  *>  id_set_pkg.add(to_a("TOP") , 

ia.3at.pkg . aapty) ) ; 

begin 

if  eq(BASE,  A) 
than 

if  eq(BASE,  B) 
than 

MERGE. tt  :*  BASE.tt; 
assign (MERGE. straaas , 

aarga.id.sats (BASE. straaas,  A. straaas,  B. straaas)); 
ratnrn  MERGE; 

also 

ratnrn  B; 
and  if; 
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else 

if  eq(BASE,  B) 
than 

rat urn  A; 

•Isa 

if  eq(BASE,  B) 
than 

return  A; 

•1m 

ratura  conflict .trigger ; 
and  if; 

•ad  if; 

•ad  if; 

•ad  eerge. trigger a ; 

function  Mrga.tr iggerj asps (VERTS:  id_s«t;  BASE,  A,  B:  t rigger. *ap) 

return  t rigger _eap  is 


MERGE:  trigger .nap; 

base. trig,  a.trig,  b.trig,  ■arga.trig  :  trigger; 
begin 

assign (MERGE,  enpty.trigger.nap) ; 
for  id  :  psdl.id  in  id.set.pkg.  scan  (VERTS)  loop 
base.trig  fetch(BASE,id); 

•.trig  :■  fetch (A, id); 
b.trig  :*  f etch (B, id) ; 

Mrge.trig  :■  ■erge.triggers (base.trig ,  a.trig,  b.trig); 
bind (id,  *erge_trig,  MERGE); 

«nd  loop; 
return  MERGE; 
end  serge.trigger.naps ; 

function  Mrge_«xpr«ssions (BASE ,  A,  B  '.expression)  return  expression  is 

local.base  :  expression; 
local.a  :  expression; 
local.b  :  expression; 
conflict. expression  :  constant  expression  :■ 

create. ident if ier (t o.a ( M**COSFLICT**M ) ) ; 
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assign (local.basa,  BASE); 
aaaigadocal.a,  A); 
assigndocal.b,  B); 
if  aq (local .BASE,  local. a) 
than 

if  aqClocal.BASE,  local.B) 
than 

ratnrn(local.BASE) ; 

alsa 

ratum  (local.B) ; 
and  if; 

alaa 

if  aq (local. BASE ,  local.B) 
than 

ratum(local.A)  ; 

alsa 

if  aq(local.A,  local.B) 
than 

ratum  (local.  A) ; 

alsa 

ratum  conflict.azprassion; 
and  if; 
and  if; 
and  if; 
and  narga.axprassions ; 

function  narga_axac_guard_naps (VERTS :  id. sat;  BASE,  A,  B:  azac.guard.nap) 

ratum  azac.guard.nap  is 

MERGE:  axac.guard.nap; 

tasa.ag,  a_ag,  b.ag,  narga.ag  :  azprassion; 
bugin 

assign  (MERGE,  aapty.axac_guard.nap) ; 
for  id  :  psdl.id  in  id.sat.pkg. scan (VERTS)  loop 
assign (basa.ag,  fatch(BASE,id)); 
assign (a.ag,  fatch(A,id)) ; 
assign  (b.ag,  fatch(B.id)) ; 

assign (narga.ag,  narga.azprass ions (basa.ag,  a_ag,  b.ag)); 
bind(id,  narga.ag,  MERGE); 
and  loop; 
ratum  MERGE; 

and  narga.axac_guard.naps; 


function  aarga. output .guard.aaps (BASE,  A,  B:  out.guard.aap) 

rot urn  out.guard.aap  is 

MERGE:  0ut.4p1ard.Bap  :■  aapty_out.guard.aap; 
basa.og,  a_og,  b.og,  aorgo.og  :  azprossion; 

bogin 

for  id  :  output. id,  a:  azprossion  in  out _guard.aap.pkg. scan (BASE)  loop 
if  aoabar(id,A)  and  aaabar(id,B) 
than 

assign (a_og,  latch (A, id)) ; 
assign (b.og,  fateh(B.id)) ; 

assign (aorgo.og,  aorgo.ozprossions(o,  a_og,  b.og)); 
bind(id,  aorgo.og,  MERGE); 
ond  if; 
and  loop; 

for  id  :  output .id,  o  :  azprossion  in  out_guard_aap_pkg.scan(A)  loop 
if  not  aaabor(id,  MERGE) 
than 

if  aoabor(id,  B) 
than 

assign (baso.og,  aapty. azprossion) ; 
assign (b.og,  fatch(B,id)); 

assign (aorgo.og,  aorgo.ozpross ions (baso.og,  0,  b.og)); 
bind(id,  aorgo.og,  MERGE); 

also 

if  not  aoabor(id,  BASE) 
than 

bind (id,  0,  MERGE); 
and  if; 
and  if; 
and  if; 
and  loop; 

for  id  :  output. id,  0  :  azprossion  in  out _guard.nap.pkg. scan  (B)  loop 
if  not  aoabar(id,  MERGE)  and  not  aoabar(id,  BASE) 
than 

bind(id,  a,  MERGE); 
and  if; 
and  loop; 
rat  urn  MERGE; 

and  aargn_output_guard_aaps; 


HmcIImi  aexge.excep.triggarjaap*  (BASE ,  a,  B:  excep.tr igger.aap ) 

return  excep.trigger.aap  is 


MERGE:  excep.trigger.aap ; 

base.et ,  n_st,  b_st,  aerge.et  :  expression; 

begin 

assign (MERGE,  eapty.excep_trigger.aap) ; 

for  id :excep_id,e: expression  in  excep_trigger.aap.pkg. scan (BASE)  loop 
if  aeaber(id,A)  and  aeaber(id,B) 
then 

assign ( a. at ,  fetch (A, id)) ; 
assign (b.et,  f etch (B, id)) ; 

assign (aerge.et ,  aerge. expressions (e,  a.et,  b.et)); 
bind (id,  aerge.et,  MERGE); 
end  if; 
end  loop; 

for  id:excep_id,e:expression  in  excep_trigger.aap.pkg . scan (A)  loop 
if  not  aeaber(id,  MERGE) 
then 

if  aeaber(id,  B) 
then 

assign (base.et ,  eapty. express ion) ; 
assign (b.et,  f etch (B, id)); 

assign (aerge.et,  aerge.express ions (base.et ,  e,  b.et)); 
bind(id,  aerge.et,  MERGE); 

else 

if  not  aeaber(id,  BASE) 
then 

bind(id,  e,  MERGE); 
end  if; 
end  if; 
end  if; 
end  loop; 

for  id :excep.id,e: expression  in  excep_trigger.aap.pkg.  scan (B)  loop 
if  not  aeaber(id,  MERGE)  and  not  aeaber(id,  BASE) 
then 

bind(id,  e,  MERGE); 
end  if; 
end  loop; 
return  MERGE; 

end  aerge.excep.trigger.aaps ; 
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function  aorgo.tiaor.op.sots(BASE,A,B:tiaor.op.sot)  rotura  tioer_op_s«t  is 

% 

MERGE  :  tiaor.op.sot ; 
bsgin 

for  t.op  :  tiaor.op  in  tiaor.op.sot.pkg- ocan (BASE)  loop 
if  aoabor (t .op ,  A) 
than 

if  aoabor (t.optB) 
thon 

odd (t. op, MERGE) ; 
ond  if; 
ond  if; 
ond  loop; 

for  t.op  :  tiaor.op  in  tiaor.op.sot.pkg. ocan(A)  loop 
if  not  aoabor (t.op .MERGE) 
thon 

if  aoabor (t.op , B) 
thon 

odd (t.op, MERGE) ; 
ond  if; 
ond  if; 
ond  loop; 

for  t.op  :  tiaor.op  in  tiaor.op.oot.pkg.ocanCB)  loop 
if  not  aoabor (t.op, MERGE) 
thon 

if  aoabor (t.op, A) 
thon 

odd (t.op , MERGE) ; 
ond  if; 
ond  if; 
ond  loop; 
rotum  MERGE; 
ond  aorgo.tiaor.op.sots; 
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fwetiw  aazgs.tiaar.sp.aapo (VERTS :  id.sat ;  BASE,  A,  B:  tiMr.op.aap) 

raturn  tissr.op.ssp  is-- 


MERGE:  tiaar.op.aap; 

bsss.sst,  a.sat,  b.sst,  aorgs.sst  :  tiaar.op.sat ; 
bsgin 

assign (MERGE,  SBpty.tiasr.op.Bsp) ; 
for  id  :  psdl.id  in  id.sot.pkg. scan (VERTS)  loop 
assign  (bsss.sst,  fatch(BASE.id)) ; 
assign(a_8st,  fstch(A.id)) ; 
assign (b.sst ,  fstcb(B.id)) ; 

assign (sorgs.sot,  aargo.tinor.op.sstsCbasa.sat ,  a.sat,  b.sat)); 
bind (id,  aargo.sat,  MERGE) ; 
and  loop; 
rsturn  MERGE; 
and  aarga_tiaar.op.aaps; 

function  aarga.t iaing.data(BASE ,  A,  B:  aillisac)  rsturn  aillisac  is 
bsgin 

if  BASE  -  A 
than  if  BASE  *  B 
than  rsturn  BASE; 
alsa  rsturn  B; 
and  if; 

alsa  if  BASE  -  B 
than  rsturn  A; 
alsa  if  A  •  B 
than  rsturn  A; 
alsa  rsturn  systaa.aaz.int; 
and  if; 
and  if; 
and  if; 

and  aarga.t iaing.dat a; 
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function  nerge_period(BASE,  A,  B:  tining.nap)  roturn  tiaing_aap  is 

MERGE:  tining.aap; 

BASEVAL,  AVAL,  BVAL:  nillisoc  0; 

begin 

assign (MERGE,  onpty.tiaing.nap) ; 

for  id:  psdl.id,  n:  nillisoc  in  tining.nap.pkg. scan (BASE)  loop 
if  noabor(id.  A)  and  nonbor(id,B) 
than 

AVAL  :»  fetch (A,  id); 

BVAL  :«  fetch(B,  id); 

bind(id,  nerge.tining.dat a (a, AVAL, BVAL) ,  MERGE); 
end  if; 
end  loop; 

for  id:  psdl.id,  n:  nillisoc  in  tining.nap.pkg. scan (A)  loop 
if  not  aenber(id,  MERGE)  and  not  noaber(id,BASE) 
then 

if  neaber(id,  B) 
then 

BVAL  :■  fetch (B,  id); 
if  a  /■  BVAL  then 
bind  (id,  systa.naz.int,  MERGE); 
end  if; 

else 

bind(id,  n,  MERGE); 
end  if; 
end  if; 
end  loop; 

for  id:  psdl.id,  a:  nillisoc  in  tining.aap.pkg.  scan  (A)  loop 
if  not  aeaber(id.  A)  and  not  naaber(id,BASE) 
then 

bind (id,  a,  MERGE); 
end  if; 
end  loop; 
return  MERGE; 
end  norgo.poriod; 
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fnetiw  (BASE.  A,  B:  tiaing_aap)  return  tining.aap  is 

MERGE:  tining_nap; 

BASEVAL,  AVAL,  BVAL:  nillisec  :«  0; 

begin 

assign (MERGE,  enpty.tining.nap); 

for  id:  psdl.id,  n:  nillisec  in  tining.nap.pkg.aean(BASE)  loop 
if  neaber(id.  A)  and  aeaber(id,B) 
then 

AVAL  :-  fetch (A,  id); 

BVAL  :«  fetch(B,  id); 
bind(id,  nerge.net (n, AVAL, BVAL) ,  MERGE); 
end  if; 
end  loop; 

for  id:  psdl.id,  a:  nillisec  in  tiaing.nap.pkg. scan (A)  loop 
if  not  aenber(id,  MERGE)  and  not  neaber(id.BASE) 
then 

if  neabe~*(id,  B) 
then 

BVAL  :-  fetch(B,  id); 
if  a  /-  BVAL  then 
bindCid,  systea.aax.int,  MERGE); 
end  if; 

else 

bind(id,  a,  MERGE); 
end  if; 
end  if; 
end  loop; 

for  id:  psdl.id,  a:  nillisec  in  tiaing.aap.pkg.  scan  (A)  loop 
if  not  aeaber(id.  A)  and  not  a  saber  (id,  BASE) 
then 

bindCid,  a,  MERGE); 
end  if; 
end  loop; 
return  MERGE; 
end  aerge.f v.or.art ; 
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function  asrgs.acp (BASE ,  A,  B:  millisac)  ratnrn  sillisac  is 

A.DIFF.BASE,  B.DIFF.BASE,  A.INT.B:  millissc; 

bsgin 

if  A  >-  B 

then  A.IHT.B  :■  B; 

•lss  A.IHT.B  :»  A; 
and  if; 
if  BASE  <-  A 
than  A.DIFF.BASE  A; 

•1*«  A.DIFF.BASE  :■  syrtsn.nax.int ; 

•ad  if; 
if  BASE  <-  B 
than  B.DIFF.BASE  B; 

•ls«  B.DIFF.BASE  :■  systsa.nax.int ; 
and  if; 

if  A.DIFF.BASE  >«  A.IHT.B 
than  if  A.DIFF.BASE  >■  B.DIFF.BASE 
than  ratnrn  A.DIFF.BASE; 
alsa  ratnrn  B.DIFF.BASE; 
and  if; 

alsa  if  A.IHT.B  >-  B.DIFF.BASE 
than  ratnrn  A.IHT.B; 
alsa  ratnrn  B.DIFF.BASE ; 
and  if; 
and  if; 

and  sarga.acp; 
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fttetiw  asrga  join.  call. par  (BASE,  A,  B:  tiaing_aap)  rvtnn  t i*ing_**.p  is 


MEUSE :  tiaing.aap; 

BASEVAL,  AVAL,  BVAL:  aillissc  0; 


bagin 

assign (MERGE,  sapty.tiaing.Bap); 

for  id:  psdl.id,  a:  aillissc  in  tiaing.aap.pkg.scanCBASE)  loop 
if  asabsr(id.  A)  and  asabsr(id,B) 
than 

AVAL  :«  fstchCA,  id); 

BVAL  :«  fstchCB,  id); 
bind (id,  asrgs.acp(a,AVAL,BVAL) ,  MERGE); 
and  if; 
and  loop; 

for  id:  psdl.id,  a:  aillissc  in  tiaing.aap.pkg. scan (A)  loop 
if  not  aaabarCid,  MERGE)  and  not  aaabar(id,BASE) 
than 

if  aaabarCid,  B) 
than 

BVAL  :-  fstchCB,  id); 
if  a  /-  BVAL  than 
bindCid,  systaa.aaz.int,  MERGE); 
and  if; 

alsa 

bindCid,  a,  MERGE); 
and  if; 
and  if; 
and  loop; 

for  id:  psdl.id,  a:  aillissc  in  tiaing.aap.pkg. scan ( A)  loop 
if  not  aaabarCid,  A)  and  not  aaabarCid, BASE) 
than 

bindCid,  a,  MERGE); 
and  if; 
and  loop; 
ratnrn  MERGE; 
and  aarga.ain.call.par; 

and  proto.iapl.aarga.pkg; 
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5.  prototype_dependency_graph_pkg 


:  PACKAGE  PROTOTYPE.DEPENDENCY_GRAPH.PKG 
(  prot ot ypa_dapandancy.gr aph_pkg_s .a  ) 

:  Used  to  parf ora  change-nerging  on  prototype 
dependency  graphs. 

:  David  A.  Daapier 
:  19  April  1994 
:  Ada 

:  Sun  Ada  1.0 

:  Provides  specifications  for  the  functions  necessary 
to  aerge  PSDL  prototype  dependency  graphs. 


with  TEXT.IO;  use  TEXT. 10; 
with  a_st rings;  use  a_ strings; 
with  generic.nap.pkg; 
with  generic.set.pkg; 

with  psdl.concrete_type.pkg;  use  psdl.concrete_type.pkg; 

with  psdl_graph_pkg;  use  psdl_graph_pkg ; 

with  psdl.conponent.pkg;  use  psdl.conponent.pkg; 

package  prototype.dependency_graph.pkg  is 

procedure  assign(z:  in  out  edge.set;  y:  in  edge.set)  renanes 
•dge.set.pkg . assign ; 

type  prototype.dependency .graph  is  new  psdl.graph; 

function  earpty.PDG  return  proto type. dependency .graph ; 

function  build_PDG(P:  in  psdl.conponent) 

return  prototype.dependency  .graph; 

function  preserved_part  (Base ,  A  ,B :  in  prototype.dependency .graph) 

return  prototypa.dapandancy .graph ; 

function  create_slice(G:  in  prototypa_dapandancy_graph ; E :  in  edge) 

return  prototype.dependency .graph; 

function  create.slice(G:  in  prot ot ypa.dapendancy.graph ; E :  in  edge.set) 

return  prototype.dependency .graph; 


--  COMPONENT  NAME 

—  USAGE 

—  AUTHOR 

~  DATE  OF  CREATION 
--  LANGUAGE  USED 

—  COMPILER  USED 
--  PURPOSE 
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function  compare. el ice* (SI  ,S2 :  in  prot o type, dependency .graph ) 

return  boolean;  » 

function  graph_union(Gl ,G2 :  in  prototype. dependency_graph) 

return  prototype.dependency. graph; 

function  graph_nerge(Gl ,G2,G3:  in  prototype.dependency.graph) 

return  prototype.dependency .graph; 

function  af f act ed.part (G , B :  in  prototype.dependency.graph) 

return  prot otype.dependency .graph; 

function  conpare_grapha  (G 1 , G2 , S :  in  prototype.dependency .graph) 

return  boolean; 

end  prototype.dependency_graph.pkg ; 


pacing*  body  prototyp*_d*p*nd*ncy_graph_pkg  is 


function  eapty.PDG  return  prototype. dependency^graph  is 
bogin 

return  •■pty.psdl.graph ; 
end; 


—  Ibis  function  takas  a  PSDL  component  and  creates  from  the 

—  implementation  graph,  a  prototype  dependency  graph. 


function  build_PDG(P:  in  psdl. component) 

return  prototype.dependency.graph  is 

6:  prototype.dependency  .graph; 

0:  psdl.id; 

VERTS:  id.set; 
u Ul' EDGE:  a.string; 

begin 

assign (G,  anpty.PDG); 

assign (G ,  prototype.dependency .graph (graph(P) ) ) ; 
assign (VERTS ,  vertices (G)) ; 
for  id:  psdl.id  in  id.set.pkg . scan (VERTS)  loop 
if  equal  (successors  (id,  G),  enpty.id.set) 
then 

OUTEDGE  :*  copy(idkEXT) ; 
assign (G,  add.edge(id,  EXT,  OUTEDGE,  G,  0)); 
if  not  has.  vertex  (EXT,  G) 
then 

assign(G,  add. vert ex (EXT,  G)); 
end  if; 
end  if; 
end  loop; 
return  G; 
end  build_PDG; 


This  function  calculates  tho  part  of  Base, A, and  B  which  are  identical.* 


function  preserved.part  (Bass , A , B :  in  prototype. dependency .graph) 

return  prototype.dependency.graph  is 

PP,  SI,  S2,  S3:  prototype.dependency.graph; 

£:  edge; 

D:  edge.set; 

begin 

assign (PP,  enpty.PDG); 
assign (SI,  enpty.PDG) ; 
assign (S2,  enpty.PDG); 
assign(S3,  enpty.PDG); 
assign (D,  edges (Base)); 
for  E:edge  in  edge.set .pkg. scan (D)  loop 
assign(Sl,  create.sl ice (Base,  E)); 
assign (S2,  create.slice(A,  E)); 
assign (S3,  create_slice(B,  E)); 

if  conpare_slices(Sl,  S2)  and  then  conpare.slices (SI ,  S3) 
then 

assign(PP,  graph_union(Sl,  PP)); 
end  if; 
recyde(Sl) ; 
recycle (S2) ; 
recycle (S3) ; 
end  loop; 
return  PP; 
end  preserved.part ; 
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This  function  creatas  a  graph  which  contains  only  tho  part  of  G  which** 
affocts  tho  output  values  written  to  the  edge  E. 


function  create.sliceCG:  in  prototype.dependency.graph;E:  in  edge) 

return  prototype_dependency.graph  is 

SI,  S2:  prototype.dapandancy .graph ; 

D:  edge; 

C:  edge.set; 

begin 

assignCSl,  enpty.PDG) ; 
assign(S2,  enpty.PDG); 
if  has.edgeCE.x,  E.y,  G)  then 
assignCSl,  add_edgeCE.x,E.y,E.streaa.nane, 

SI,  latency(E.x,E.y,E.strean_naae,G))) ; 
assignCSl,  add.  vert  ex  (E.x,  SI,  aaxinun.execution_tine(E.x,G))) ; 
if  eqCE.y.  EXT) 
then 

assignCSl,  add.vertexCE.y,  SI)); 
end  if; 

assignCC,  edgesCG)); 
while  not  conpare.slicesCSl,  S2)  loop 
assign CS2,  SI); 

for  D:edge  in  edge.set  .pkg.scanCC)  loop 

if  Chas.vertexCD.y,  SI)  and  not  eqCD.y,  EXT)) 
then 

assignCSl,  add.edgoCD.x,D.y, 

D . st r ean.naae , S 1 ,  lat ency CD . x , D . y , D . s t r ean.nane , G ) ) ) ; 
assignCSl,  add. vert ex CD. x,  SI, 

■axinun_execution.tineCD.x,G))) ; 

end  if; 
end  loop; 
end  loop; 
end  if; 
return  SI; 
end  create.slice; 
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—  This  function  cdalatM  tha  union  of  tho  graphs  G1  and  G2. 


function  graph. uni on (G1,G2:  in  prototypo.dapandnncy .graph) 

roturn  prototypo.dopondoncy.graph  is 

G:  prototypo.dopondoncy .graph; 

V:  padl.id; 

V:  id.aot; 

E:  odgo; 

D:  odgo.sot ; 

bogin 

assign(G,  onpty.PDG) ; 
assign (G,G1); 
assign (V,  vorticos(G2)) ; 
assign(D,  odgos(G2)); 
for  V:psdl.id  in  id.sot.pkg. scan (tf)  loop 
if  not (has.Tortox (V ,  G)) 
than 

assignCG,  add.Yartaz(V,  G,nazi*u*.azacution.ti*nCV,G2))) ; 
and  if; 
and  loop; 

for  E:adga  in  adga.sat.pkg. scan (0)  loop 
if  not  (adga.sat.pkg.naabar(E,adgas(G))) 
than 

assignCG,  add.adga(E.z,E.y, 

E.straan.nana,  G,latancy(E.z,E.y,E.straan.naao,G2))) ; 

and  if; 
and  loop; 
rat  urn  G; 
and  graph.union; 
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This  function  aorgos  thro*  graphs  using  tho  function  graph.union. 


function  graph.aerge(Gl,G2,G3:  in  prototypo.dopondoncy.graph) 

return  prototypo.dopondoncy.graph  is 

G:  prototypo.dopondoncy.graph ; 

begin 

assign (G,  eapty.PDG); 
assign(G,  graph.unio" (Gl,  G2)); 
assign(G,  graph.union (G,  G3)>; 
return  G; 
end  graph.aorgo; 


—  This  function  calculatos  the  part  of  G  which  is  not  contained  in  P. 

function  affoctod.part (G,B:  in  prototypo.dopondoncy.graph) 

return  prototypo.dopondoncy.graph  is 

A,  SG,  SB:  prototypo.dopondoncy .graph ; 

E:  edge; 

D:  odgo.sot; 

begin 

assign (A,  eapty.PDG); 
assign (SG,  oapty.PDG) ; 
assign (SB,  eapty.PDG); 
assign (D,  odgos(G)); 
for  E:edge  in  odgo.sot .pkg. scan (D)  loop 
assign (SG,  create.slico(G,  E)); 
assign (SB,  cr*ato.slico(B,  E)); 
if  not  coaparo.slic*s(SG,  SB) 
then 

assign(A,  add_odgo(E.z,E.y, 

E.stroaa.naao,  A,  latency(E.z,E.y,E. stroaa.naao.G))) ; 
assign (A,  add_v*rt*x(E.x,  A,  aaxiaua.*x*cution_tia*(E.x,  G))); 
assign (A,  add_v*rt*x(E.y,  A,  aaxiaua.oxocut ion.t iao (E . y ,  G))); 
end  if; 
ond  loop; 
return  A; 

ond  aff octod.part ; 
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—  This  function  coaparas  ths  graphs  61  and  62  with  raspact  to  tha 

—  slica  S.  If  aach  of  61  and  62  ara  tha  suta  with  raspact  to  S,  than 

—  it  ratorns  TRUE. 


function  coapara.gr aphs (6 1,G2,S:  in  prototypa.dapandancy .graph) 

ratum  boolaan  is 


E:  adga.sat; 

T,  V:  prototypa.dapandancy  .graph; 
bagin 

assign (T,  aspty.PDG); 
assign (V,  aspty.PDG) ; 
assign (E,  adgas(psdl.graph(S) ) ) ; 
assign (T,  craata_slica(Gl,  E)); 
assign (V,  craata_slica(62,  E)); 
raturn(coapara_slicas(T,  V)); 
and  cospara.gr&phs ; 

and  prototypa.dapandancy.graph.pkg; 
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